[Prev][Next][Index][Thread]
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).
Sujal
Follow-Ups:
References: