Date: Sun, 4 Feb 96 12:16:48 MST From: nelson@santafe.edu (Nelson Minar) To: Paul Traina <pst@shockwave.com> Cc: Sujal Patel <smpatel@wam.umd.edu>, Thomas Davis <Thomas.Davis@mnscorp.com>, multimedia@freebsd.org, linux-connectix@crynwr.com Subject: Re: real-world experience with QuickCam in the kernel Message-ID: <9602041916.AA28208@sfi.santafe.edu> In-Reply-To: <199602031007.CAA00405@precipice.shockwave.com> References: <Pine.BSF.3.91.960202151623.188E-100000@xi.dorm.umd.edu> <199602031007.CAA00405@precipice.shockwave.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>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. This will be a problem (how big?) for motion video, but won't matter at all for someone who just wants to make snapshots. I really want to be able to do "ppmtogif < /dev/quickcam > snapshot.pgm". Maybe the solution is to put in a device driver, but have one of the options somehow be to hand over control of the camera to a user process if they want to go to the trouble of hacking the camera themselves. Something would have to be done to insure they don't screw up the camera, though. I looked at an SGI's camera yesterday, by the way, and got seriously bummed. 30fps 640x480 full colour, no noticeable load on the machine. I guess that's what you get when you have real IO. Of course, my Linux box with QuickCam was 3x cheaper :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9602041916.AA28208>