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.

> 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).


Follow-Ups: References: