[Prev][Next][Index][Thread]
Re(2): Re(2): Re(2): Quickcam device driver for Linux
jkf@tiger.franz.com,Internet writes:
> This has the device-driver-like advantage of keeping clients away
>from the camera but doe
>s a lot more: e.g. clients can be anywhere
>on the network, the server code can enhanced t
>o do interesting
>things such as auto brightness/contrast, sending deltas, sending
>recent p
>ictures rather than waiting for another capture. There's
>lots of room for experimentatio
>n.
Very good, my only concern then is performance, i.e. kernel context
switching and network driver/propigation overhead, let's take the case of a
"realtime" movie vewer running under X11 on the same machine as the camera
server to see what has to happen; Let's assume the viewer and server are
allready running and connected to one another via socket connection. The
viewer reads in a image via the parallel port, each read of the parallel
port consists of a context switch from user space to kernel space and back
to user space again. Then the server pipes the data upstream to the viewer,
where each write on the pipe constitutes another context switch from user
space to kernel space and back again, the network driver (and/or cable) is
then bogged briefly with piping the image upstream, now the viewer switches
back and forth from user to kernel space to read from the pipe, the viewer
then maps the image to an X11 window, this constitutes a series of reads
and writes on the X11 pipe which can be translated into a series of context
switches and again some network driver/cable traffic, then the X11 display
(server) has to map the image to physical video memory which constitutes
another series of context switches, then you see your image on the
screen...
Each of these steps alone may appear to be a trivial amount of overhead,
but it's the case where you add it all up for each and every frame that
causes me concern when you start talking about "near real time" video. I
don't know for a fact that performance would be a problem, but it should be
considered I think.....
Another argument for developing a camera device driver is the case where
you're not talking about a "QuickCam(tm)", after all, there are other
digital camera vendors, and will probably be many more in the future. When
you start talking about this aspect of it, a device driver really starts to
make sense for the same reason other device drivers make sense, you have a
common API for accessing that "type" of device and the device driver alone
only has to know how it "really" works. In this way, applications
(including a TCP/IP camera server) don't have to be rewritten (or even
recompiled) to work with different camera devices. This is why I refered in
my earlier example to (/dev/camera) rather than (/dev/qcam), because I
generally tend to think of devices on a unix box as generic devices of some
"type" or "class" rather than a particular brand or make. Although, I
admit this is probably the wrong place to be making such an argument since
this *is* the QuickCam(tm) device mailing list! ;)
Mike Sharkey
X11 Development
SoftArc Inc.
Tridem Labs
Follow-Ups:
References: