Date: Sat, 03 Feb 1996 11:35:17 -0800 From: Paul Traina <pst@shockwave.com> To: Sujal Patel <smpatel@wam.umd.edu> Cc: Thomas Davis <Thomas.Davis@mnscorp.com>, multimedia@freebsd.org, linux-connectix@crynwr.com Subject: Re: real-world experience with QuickCam in the kernel Message-ID: <199602031935.LAA02882@precipice.shockwave.com> In-Reply-To: Your message of "Sat, 03 Feb 1996 14:28:18 EST." <Pine.BSF.3.91.960203142358.256F-100000@xi.dorm.umd.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
From: Sujal Patel <smpatel@wam.umd.edu> Subject: Re: real-world experience with QuickCam in the kernel 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. This is a win, not a lose. Actually, we want them to take away our time slice while we're in the sync/wait loop. > 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 :) Yep, in that case, spend $300 on a matrox meteor. ;-) > 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. Sure. > 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? Well, I have heard the CCD image fades, but that must be tenths of seconds after, not microseconds. We should have all of the time in the world is my _conjecture_. I haven't re-coded the routines yet, so I wouldn't know for sure. > 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).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602031935.LAA02882>