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 standard. 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
> applications.
>
> Do you mean that all these applications use the v4l or v4l2 interface
> incorrectly?
>
> 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
> APIs.

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).

Peter

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 instead).

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 webcam.

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 scenario.

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: 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?

And 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...