From owner-freebsd-multimedia Sat Feb 3 11:28:37 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA22926 for multimedia-outgoing; Sat, 3 Feb 1996 11:28:37 -0800 (PST) Received: from xi.dorm.umd.edu (xi.dorm.umd.edu [129.2.152.45]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA22912 for ; Sat, 3 Feb 1996 11:28:28 -0800 (PST) Received: from xi.dorm.umd.edu (localhost [127.0.0.1]) by xi.dorm.umd.edu (8.7.3/8.6.12) with SMTP id OAA02482; Sat, 3 Feb 1996 14:28:19 -0500 (EST) Date: Sat, 3 Feb 1996 14:28:18 -0500 (EST) From: Sujal Patel X-Sender: smpatel@xi.dorm.umd.edu To: Paul Traina cc: Thomas Davis , multimedia@freebsd.org, linux-connectix@crynwr.com Subject: Re: real-world experience with QuickCam in the kernel In-Reply-To: <199602031921.LAA02828@precipice.shockwave.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@freebsd.org Precedence: bulk On Sat, 3 Feb 1996, Paul Traina wrote: > Think about it, same I/O operations need to be done, and when you open > /dev/io, you're doing them directly from user-mode. Yea, but in user-mode you have to deal with other processes taking away our time slice. In FreeBSD, we can use rtprio-- But I dunno about what the Linux folks can do about this. > Even then, taking an interrupt per nibble would be ugly. The QuickCam would also need an onboard frame-buffer. Maybe signal when the whole frame was ready. But! Enough wishing :) > Since we're gated by the speed of the spin loop anyway, we may as well hit > the "go" button as soon as possible and then do the stuff that's slow on > the processor. You could probably code the shifts in LISP and it would > still complete before the sync/wait completed. :-) I was thinking of something along the same lines. But of course coding it in assembly never hurts so I thought, I'd throw it out. > Are you sure it's instant? I think we have several tens of microseconds of > slack here, don't we? If not, then my proposal for reordering the xfer > routines won't fly. The way I understand the QuickCam's operation: You need to read it as fast as possible? Or am I wrong on this point? > I found a bug in my code comparing it to xfqcam, but I still haven't fixed > my hardware to do bidir. I need to fix this myself- I think it's a subtle bug which exists in all of the bi-directional code (or maybe I just have funky hardware). Sujal