[Prev][Next][Index][Thread]
Re: Quickcam device driver for Linux
On Sun, 15 Jun 1997, Thomas Davis wrote:
> On Sun, 15 Jun 1997, Eric Berenguier wrote:
>
> > Hello,
> >
> > On Sat, 14 Jun 1997, Thomas Davis wrote (about qcam driver) :
> > > been there, done that.
> > > you'll find that the qcam hardware will kill that driver.
> > > you end up with no system interrupts will pulling a picture off the
> > > camera, and really jerky system response.
> > > No, there really is no way to fix this.
> >
> > I don't agree with you. Standard printer driver works in a similar way
> > and does not have problems you talk about.
> >
>
> You haven't printed a large enough document, to a Laserjet 6mp with 19megs
> of ram in it..
>
> It gets jerky.
It all depends on the transfer speed and possible consequences of
delays. For regular printer speed is very low and delays are harmless.
For that printer with large RAM speed sometimes is high, although
delays are tolerable. B&W Quickcam has higher transfer speed than printer,
and delays are dangerous. Color Quickcam transfers 3-4 times more data
than B&W one with, I believe, the same requirements for the total transfer
time of the frame. In addition to all troubles, IMHO there is no
reasonable delay that can be inserted between pixels or groups of pixels
that will be definitely safe, so the decision, when to delay polling and
let other processes do something, is tricky. One test version of qcread
used realtime priority, and pictures were perfect -- just the system
looked like very advanced version of DOS after such grabber was started.
In kernel problem can be solved by very careful sleeping, but qcread just
remained in user space, and timing problem was more or less solved by
changing its priority while reading (it probably should be smarter at
assigning priority, but mostly it's ok, and I don't think, kernel driver
will have any advantage over that). Another problem is buffer size. For
color Quickcam in 320x240 mode it's 250K, and there is no way to read less
than that at once because of timing.
Another reason for kernel driver may be the need to use camera by
programs that shouldn't be started by root or be setuid root. It may be a
valid reason, but I think that Quickcam is not a "safe" device to be
handled by regular user program anyway -- it either sucks large amount of
processor time or produces unusable images, and since I consider camera to
be close to scanners in functionality, and scanners are handled by
user space programs through generic SCSI device driver (hpscanpbm, SANE,
xvscan), camera can remain user-space-handled device without
significant harm to the concept of device.
--
Alex
Follow-Ups:
References: