Yesterday I bought a Microsoft webcam: it's not an exception, like most of the stuff from Microsoft I had (very little, fortunately) something to do with in my
life it's a low quality product: all eye candy and little substance.
However it has a good point, that is one of the main reasons I bought it: the Lifecam NX6000 is a device compatible with the USB video class
In brief USB is not just a low level bus, it also defines the way some class of devices communicate with the operating system: this is the reason why we don't need to install specific mouse drivers anymore and why most USB microphones will work out of the box.
USB defines a device class for video devices, that is the UVC (USB Video Class)
that new webcams are starting to implement, so my webcam can work just using
the generic uvcvideo
Linux driver without to require a device-specific
driver, exactly like a mouse or an USB microphone.
Video For Linux 1.0 VS Video For Linux 2.0
Actually the uvcvideo
diver works well with my camera, but this
driver supports only
the new video API of Linux, v4l2 (Video For Linux 2):
this means that the majority of the software currently available
can't work with my driver that dropped the support for v4l version 1.
This is not the only driver without support for v4l1 (alias for
a lot of applications people are currently using). There was this
fantastic idea that everything was going to be converted in short time,
applications can be patched after all, and even that the support for
v4l1 itself was going to be completely dropped from the kernel soon.
Check what this kernel developer is saying here...
> No, I still haven't tried Ekiga (I'm going to test it when I have the
> time), but I still need to have the webcam working with all these other
> Do you mean that all these applications use the v4l or v4l2 interface
> Do you have plans to have v4l1 compatibility in the driver?
> I still don't know what ioctls should be in a v4l2 driver with v4l1
> compatibility using v4l_compat_translate_ioctl()
> Do you know where I can find that list?
> Do you know of a good webcam USB driver that has good v4l1 compatibility
> using v4l_compat_translate_ioctl() ?
> I saw http://www.saillard.org/linux/pwc/ but it has both v4l1 and v4l2
I don't see the point in adding V4L1 support as its due to be removed
from the kernel before too long (can't remember the exact proposed
kernel release but it may be 2.6.18).
I'm very impressed. We used the old v4l1 API for years and now there is the idea that this API can be dropped in short time without problems, that new drivers are not required to support it, and that there is no reason to build a working
compatibility layer (there is one that can't work since
the output image format is not one of the standard v4l1 formats but is MJPG
Of course the v4l1 support was not dropped in 2.6.18
since it was like science fiction. The current situation basically is that if you get the
wrong webcam with drivers developed by the wrong people, you have a mostly
useless toy you can use just with few cam viewers using the 2.0 API and
some softwares already compatible with the new API like recent versions
of Egika and a few of others.
This is a point of view perfectly right for engineers
, but it means
to don't have any kind of vision. If you develop a kernel you should ask
yourself "What I'm doing for people using this system every day" before
to ask "what is the best API for video devices". There is an incredibly
big failure in the Linux Kernel culture to create software that is
easy to use for the people that need to use it, all is about technical stuff
but what people need is supported, stable systems, where software of two
years ago will continue to work without patches even if you have a modern
But Linux is getting better and better as desktop OS!
True, but are you sure it is Linux
? If you take a FreeBSD install with KDE, Openoffice, Firefox, ..., it's going to be a good desktop experience exactly
like a similar Linux install: most of the progresses of "Linux" on desktop
are not about the kernel, they are about what is running on top of it.
Still I think the Linux kernel is a better alternative than *BSD
or other Unix-like open source operating systems, for two reasons: support
, and drivers
Because Linux took more momentum something like ten years ago it started
to have more developers, more money invested, more drivers, more forums,
more users, more support. It is strange but continuously changing the kernel
APIs (how many times a module implementing drivers for the XYZ device does not compile after few months because something changed in the API?) and
a non existent stable binary API
for modules, is going in the opposite
direction making support for devices harder.
A Stable API for binary drivers
Ok let's try to be interested in what happens to users instead to think
just as engineering: with a stable binary API what you have is the following
The user bought a new device needing a device driver in order to work, and like it
happens a lot of times this driver is not already included in the kernel, or the included driver is too old to support this new USB product/vendor ID.
Without a stable API the user needs to find the source code of the kernel,
download, compile (assuming it will build), insert the module.
With a stable API the user can just download the driver for Linux 2.6 and
insert it: done.
On the other side the driver developer is very motivated working on the driver,
all the work is invested in supporting the device better, not in upgrading
and creating new tar.gz just because the API changed again
(I used to
develop a device driver for an USB camera and recently I tried to take
a wifi driver I modified to support the monitor mode
up to date and
it was a pain both the times for this reason).
Note that I'm not talking about closed source drivers for now. Even if we
take all GPLed a stable binary driver is already a great thing from the
point of view of the user.
What about closed source vendor provided drivers?
One of the arguments against a stable binary driver is the following:
Linux is more stable than Windows because the device drivers are more stable!
with a stable binary API vendors will produce closed source drivers for
Linux that will crash the system every five minutes.
Is it true that Windows is instable because of drivers? After 9 years of using only Linux every day one month ago I started using Windows XP for a few hours every day: my girlfriend lives in Florence (north Italy) while I'm
currently in Catania (south Italy): MSN Live Messenger is what she used
in order to stay in touch with other people, and I had a Windows XP in dual
boot because it was installed when I purchased this laptop and I took
some space to take it in the disk (I'm a web developer and from time to time
I test applications in a real Windows environment).
Result: a lot of the things I took for granted about Windows of 9 years
ago are no longer true. Windows XP hardly crashes in a way that
is up to the device drivers it is running: actually it mostly does not crash
at all and when something goes wrong it appears to be much more related
to the operating system.
I don't thing vendor device drivers are less robust than open source drivers
that sometimes are written in spare time with little specification and testing.
For example my wifi card with wpa_supplicant hangs from time to time, and
a reboot is needed
, with Windows it works perfectly.
Another wifi usb dongle I use in Windows works very well supporting
ad-hoc networks, while with Linux it works not very well and ad-hoc
networks are not supported at all, and the list of devices working well
with Linux and not working well with Windows is of course very big.
Add to this that most drivers are throw away software: a driver for a webcam
will be useful for few years, the vendor needs
to develop it if it want
to sell the device, but isn't it a waste of time that Linux kernel developers
will spend their time to write code that in few years will be nearly useless?
closed source binary drivers will not stop everybody from producing GPL drivers:
for important parts of the system like for example the USB subsystem or the
IDE controller, and even for small devices like webcams where the vendor
driver sucks probably a GPL driver will be developed like it happens today.
So I'm starting to belive that the Linux Kernel is not going in the right
direction from the point of view of the end user, and I guess the only thing
I can do for now is to try to spread this idea trying to start some kind
of conversation among interested people.
You can vote this article on reddit
p.s. this blog used to be written in Italian, but this article is the first of the Big Switch to English, so feel free to come back if you are interested in this stuff and sorry to my old readers that can't read english very well...