[Prev][Next][Index][Thread]

Re: real-world experience with QuickCam in the kernel


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