The plot..

Some years ago, when I started using linux, I felt the need for video chat, and hence intended to buy a webcam..

Unfortunately, while most of usb hardware is standard, such as the usb mass storage class, this is not at all the case for video, although it is starting to get better with the usb video device class which is more and more used by modern webcams.

So, at this time, each webcam would have its own communication protocol, and each driver had to implement a different way of communicating with the device. Even worse, due to bandwidth limitation in the original USB 1.0/1.1 protocol, the data had to be compressed, to get a decent frame rate...

One webcam would use a tweaked JPEG algorithm, using non standard pixel patterns, for instance.. Then, the driver would need proprietary informations about this format, and would even be exposed to FUD for using a format implementing a mathematical transformation known everywhere.

Knowing this, I carefully looked on the linux-usb device overview to look for a webcam that was supported, and found out the Trust Spacecam 320, that had a reasonable price, and was supposed to be well supported.

So I went to buy one, namely a "Spacecam 320" sold by "Trust", in the (infamous) Surcouf shop in Paris. What was my surprise when I plugged it, compiled and loaded the module, and... nothing happened...

Indeed, the usb ids returned by the device where  0x05a9:0x8519 instead of 0x05a9:0xa518... Yes, they where selling two different type of hardware under the very same name... I don’t believe this is legal, at least in my country, we would call this "tromperie sur la marchandise"...

Don’t give up !

But, all in all, I had bought this webcam, so I looked around to find out how to make this new one work. I then discovered that the 519 and 518 were product number for the camera sensor, manufactured by OmniVision, and the the main difference between the two was that the 519 series was using the JPEG compression algorithm to compress the data, encapsulating it in the JFIF file format, while the old one was using a proprietary format, derived from JPEG.

Even better, the 518’s driver author had started a new driver, ov51x supporting the camera... But purposely had decided to not support the JPEG decompression in kernel-land...

The main argument for not doing it in kernel land was that the Linux kernel maintainers would never accept it, for patent reasons and separation between kernel land and userland purposes.

Unfortunately, the facts are that they even didn’t accept the proprietary decompression algorithm in the previous ov511 driver, committing a stripped driver in main kernel tree, hence completely useless...

It took me a long time to understand the separation argument between what had to be done in userland and in kernel land. In particular, it looked a bit arbitrary, since for instance cryptographic operations are also done in kernel land, or other video mangling related to DVB drivers..

After these considerations, I started looking at a userland decompression, trying to hack on a single application.. Given my coding skills at this time, and also the fact that the work would need to be done for each application, I quickly gave up, and started to look at the kernel driver.

Fortunately, the ov51x driver had a very good modular decompression API, which was simply not used for the 519 chips. So, I took a generic JPEG decompression, stolencopied from another driver, the ZC0302, and added a decompression module for the 519 chips..

After several hard kernel oops, and some times, I ended up with a purely hacked driver that was doing the decompression in kernel land, allowing a transparent usage of the webcam in any application supporting v4l.

A never ending story..

Although I though I would never maintain it anymore, people started to ask me for the driver, which I initially only made available through a simple url link. Indeed, the chip was also used in a famous webcam shipped with several playstation video games, the Eye Toy. Hence, after playing with the webcam on the playstation, there was a strong demand for using it under linux..

I then setted up a wiki, and started to maintain as much as possible the module, knowing that it would surely be useless, since the initial design choice wouldn’t be accepted upstream..

The developpement was made much more easy, thanks to numerous contributions. We even had a success story when we started supporting the Live! webcams, thanks to the collaboration with several hackers !!

Now, I don’t have enough time to maintain it anymore. The least I can do is to try to support the various new kernels, and continue adding missing usb ids.

There is a project for doing things the right way, using a v4l2 dedicated userspace library that would perform the decompression in userland, and then send back the data to the kernel space. The project is still under discussion, but Thierry, the main leader, is very kind and collaborative, so any interested hacker can join the fun and start ripping out this madness..

Conclusion

I would really like to see the v4l2 library project succeed. Even though I initialy didn’t like the separation between user and kernel land, I believe it’s really the right way to go. I would ease the task of kernel module authors, and allow to collect each strange and proprietary formats outside of the kernel, as well as being able to use main libraries for decoding standard formats.

Since I will not personally be involved anymore with this (it turned out I don’t really use the webcam, nor like video chat... !), I have written this post in the hope that it might give interest to other potential contributors, and beat the hell out of this mess !