Date: Sat, 03 Feb 1996 02:07:40 -0800 From: Paul Traina <pst@shockwave.com> To: Sujal Patel <smpatel@wam.umd.edu> Cc: Thomas Davis <Thomas.Davis@mnscorp.com>, multimedia@freebsd.org, linux-connectix@crynwr.com Subject: real-world experience with QuickCam in the kernel Message-ID: <199602031007.CAA00405@precipice.shockwave.com> In-Reply-To: Your message of "Fri, 02 Feb 1996 15:21:45 EST." <Pine.BSF.3.91.960202151623.188E-100000@xi.dorm.umd.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
[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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602031007.CAA00405>