Re: real-world experience with QuickCam in the kernel
From: Sujal Patel <firstname.lastname@example.org>
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.
> 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
> 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).