Date: Wed, 31 Jan 1996 10:14:33 -0800 From: Paul Traina <pst@shockwave.com> To: Sujal Patel <smpatel@wam.umd.edu> Cc: Paul LaFollette <lafollet@andante.cis.temple.edu>, hackers@freebsd.org Subject: Re: Any interest in Quickcam Driver Message-ID: <199601311814.KAA06818@precipice.shockwave.com> In-Reply-To: Your message of "Wed, 31 Jan 1996 10:20:34 EST." <Pine.BSF.3.91.960131101704.189I-100000@xi.dorm.umd.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
From: Sujal Patel <smpatel@wam.umd.edu>
Subject: Re: Any interest in Quickcam Driver
On Tue, 30 Jan 1996, Paul Traina wrote:
> Grrr... too bad you didn't write this about 4 hours ago. I'm about 70%
> done with a linux-compatible quick-cam driver too. :-)
Yikes! Did you follow all of the changes that were discussed on
linux-connectix@blah.blah.blah-- T. Davis (the guy who wrote the Linux
driver) and I were have some discussion on that list about a better standard
API between the Linux and FreeBSD driver. He is releasing a new kernel
driver for linux on Sunday, that should reflect the changes we discussed.
No, I hadn't gotten around to joining yet. _sigh_ :-)
Oh, BTW: My driver is over 50% done, but I'm waiting for my QuickCam
to come back- it broke :(
> Bummer, I was hoping we'd see a significant speedup with the move out of
> user mode, but direct I/O is direct I/O. I've coded up support for mmaping
> memory directly into the buffer, but polling that lpt port is still the
> bottleneck.
The driver transfers very little data and spends little time transfering
data to the user program like the current Linux driver does (relative to the
time it takes to do the direct I/O)-- mmaping shouldn't really be
neccesary IMHO.
Yeah, I think you're right. I was just trying to for that extra burn, but
the ioctl() syscall overhead (to start the next scan) is as bad as the read.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601311814.KAA06818>