Christmas is coming early for webcam
users. Support for hundreds of popular
webcams, available from Michel Xhaard's GSPCA project,
for inclusion in the upcoming 2.6.27 kernel.
The amount of tweaking required from the user, the
distribution, or both, has been cut, and it's likely
that a random webcam will now just work out of the
Even with the much-wanted drivers
becoming part of mainstream Linux, a small
matter of plumbing remains. Webcams, Hans
de Goede pointed out at the Linux
Plumbers Conference, produce a variety of
compressed video data. "They all came up
with interesting proprietary compressed video
formats," he says. The out-of-tree version of
GSPCA did some decoding in kernel space, but the
decoding of many camera-specific custom video
formats had to be ripped out, as doing
that kind of work in-kernel is a Linux faux
pas. That's where Hans's libv4l comes in. Announced
in June, the new library (actually a set of three)
does the format conversion.
While not a Red Hat employee
at the time (he is now) Hans posted a "BetterWebcamSupport"
feature idea on the Fedora wiki, writing, "Currently
many webcams do not work with Fedora out of the box
even though a Linux driver exists for them." The
problem was partly fixed with the GSPCA cleanup and
inclusion upstream, and partly became the rationale
for libv4l. Besides the core libv4lconvert library,
the package includes libv4l2, to emulate a /dev/videoX
device which, transparently to the application,
will deliver "sane" video formats. There's also a
libv4l1 to do the same thing but for the V4L1 API.
An audience member asked why the library
is separate from gstreamer, which is already
set up for video transcoding. V4L2 developer Hans
Verkuil responded from the audience that "it's
something that you do not want to have in the kernel,
but it has to be small and fast." That leaves out
gstreamer as a general solution, since some webcam
applications don't need gstreamer or can't afford
the space it takes. Therefore, a separate library.
It needs one more feature, too: vendors install
camera chips however they'll fit, which means the
same camera module could be right side up on one
product and upside down on another. Therefore,
libv4l has software support for flipping images,
but it still needs the data to know when to flip:
a table identifying which hardware has the camera
module in which orientation.
at SUSE has another piece of the puzzle,
a "frame server" that lets multiple
applications share the webcam—doing
for the webcam what PulseAudio does for the
sound hardware. You can't shoot a photo with Cheese
while another app has the webcam open, as he showed in
You can always rely on the computer hardware
industry to figure out ways to save a little money
on something if it's possible to solve the problem
in software. Many new webcams have motorized focus
but no hardware autofocus. Autofocus is up to the
host system—which means a focusing daemon needs
to see the video at the same time as an end-user
application. So providing access for the autofocus
daemon is another reason for the frame server.
Someone on the mailing list has the autofocus math
that will form the guts of the daemon figured out,
but it's a fairly intensive calculation and will
need to be done on an occasional frame of video,
not each frame.
While the original frame server idea would have
one shared memory segment per system, with access
for multiple users, PulseAudio developer Lennart
Poettering pointed out the potential security risks
of that idea from the audience. "Memory mapping
across privileges is a really bad idea," he said.
He suggested putting the frame server in the user
session to prevent users from, at least, killing each
other's webcam applications.
The webcam market is one where Linux is an
afterthought if it's a thought at all. The Linux
conferences aren't teeming with employees of webcam
manufacturers. The support Linux does have shows
that the community can still support hardware on its
own when it has to.
to post comments)