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

real-world experience with QuickCam in the kernel

[For those unaware, I wrote a QuickCam driver for FreeBSD yesterday based
 upon work done by Scott and Tom.]

Sujal,

You're going to love this. :-(

I hacked up a copy of xfqcam tonight to work with my kernel driver.

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.

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.

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.

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

Paul

p.s.   I haven't figured out why I'm having the left-column out of sync
       and flare-up bits when doing full-motion video when xfqcam
       works fine.  I'm doing the same operations as Paul and I removed
       most of the delay's in sendcommand per his suggestion (actually,
       I think he was getting bit by dismissing too long between the
       write to the data port and the sync-read.  I think the trick may
       be to implement a handshake for starting unidirectional transfers
       similar to the waitfor_bi code.  I may do that tomorrow just as
       for grins.

p.p.s. Tonight's changes (not production quality at all, just hacks)
       are available in the usual place.  You may want to note my
       comments about differences between my stuff and Paul Chinn's.
Follow-Ups: References: