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

Re: real-world experience with QuickCam in the kernel

On Sat, 3 Feb 1996, Paul Traina wrote:

> I found a couple of small bugs in my driver (no big deal), but I'm
> now convinced that without some serious head-scratching, doing this
> in kernel mode is a big lose.  In fact, due to the extra copies and
> syscall overhead, I'm at least 5% slower than xfqcam.

I guess that means I should go to sleep now? :-)
This seems almost *inconceivable* that the driver could be slower :(

> It looks like the QuickCam has no serious way of generating interrupts,
> and the spin loop synchronization locks up the system during transfers of
> a frame.  This is unnoticeable while doing single frame captures,  but
> completely sucks when doing movies.

Yeah, this really bites.  If only they wired up the ACK line, and sent an 
interrupt when it was ready to send some data.

> At this point, I think it's best if we could concentrate on documenting
> the protocol and working out an _optimized_ library and standard API
> for tools.  By optimized, I mean that xfqcam's bit-shifting operations
> run significantly faster than the standard ones everyone else is using.
> Paul's code seems to run significantly faster, which is strange given
> that his stuff is less unwound, and I see at least a few speed fixups
> I could make over his stuff without much effort.

Why not just write those scan routines in assembly...  Seriously, it's 
not that much work, and you'll be absolutely sure that they are efficent.

> I'm really unhappy and upset about this because one of my goals through
> doing this with the kernel is we would not require special privs for
> accessing I/O memory.  Unless we can figure out a way to handle this
> without kernel threads or interrupt support comming back from the QuickCam,
> I think this may spell death for all kernel drivers (at least for motion
> use...).

I dunno--  5% speed loss vs a clean interface.... It's a though call.

> I'm going to bail for tonight and sleep on this.  If someone has a good
> idea for avoiding spin-loops while in the kernel, I'm all ears.  Maybe
> I'll have a better idea in the morning.

I can't think of anything to avoid the loops..  You need to read the data 
from the QuickCam the INSTANT it offers it.

Also-- For everyone:  I finally got around to testing Bi-dir; 
Bi-directional modes are not working in any way (my code, xfqcam, and
pst's driver).  Any ideas?  If not, I'll figure it out tommorow.


Sujal
Follow-Ups: References: