Linux drivers

I bought a new input device, Wacom Bamboo Pen & Touch tablet. I was careful enough to buy an older model and to check the device is supported on Linux. Based on my previous experiences I also tested the tablet on a Windows computer to be sure it actually works and I can handle it, so that I’m sure contingent faults on Linux are caused solely by the drivers and are not hardware or user defects. Installation of the Windows driver was quick and easy and the device worked well immediately.

Then I tried to get the device running on Linux. I installed a newer 2.6 Linux version, reported to support the device, and the newest released version of X.Org Wacom drivers. I added appropriate sections to my /etc/X11/xorg.conf. So after some hours of googling and updating the system I got an environment which should be ready for testing the tablet.

I restarted the X server and ended up with a frozen black screen, having to use a reset button on my computer. This situation had repeated for several times until I discovered the Wacom driver conflicts in some way with a Wizardpen driver, causing crash of the X server without recovering the keyboard and console. So I commented out the Wizardpen input device in xorg.conf and then could start X without having to reset my computer anymore.

The pen function worked well but the touch function didn’t work well and the tablet buttons didn’t work at all. I found out that although the given model number of the tablet should be supported in newer 2.6 kernels, there are actually several variants of the model and the newer ones are not supported in those kernels. So I installed the newest version of the tablet kernel drivers for Linux 2.6.

The touch function started to work in a different but still unusable way. After some exploration I found out that while the tablet kernel drivers support several versions of 2.6 kernels, not all fixes are backported to all the supported versions. My Linux was too old so I had two options (not counting giving up on using the touch function): either to backport the changes myself or to upgrade my system to a development version. I decided to upgrade and the touch function finally started to work with a recent 3.1 kernel, after I was forced to abandon my stable OS installation (I couldn’t upgrade just the kernel because it was necessary to recompile OpenAFS modules for it, which is possible only with new gcc, which depends on new libc, etc.).

Nevertheless gesture recognition still didn’t work as expected. I had to install the latest development version of X.Org Wacom drivers to fix that.

Tablet buttons still didn’t work. After some guesswork I could get them working by changing my X.Org configuration, a wrong device was used in the sample configuration copied from wiki. After another round of googling I finished the device installation by tweaking the unsuitable acceleration settings, by adding tablet rotation support to my screen rotation script and by remapping the buttons. After many hours of googling, reading, editing, compiling, reseting and experimenting the tablet still doesn’t work as well as on Windows after five minute installation, because of the limited set of supported gestures, but at least it can now do everything my mouse can.

Lessons learned:

• Hardware vendors still mostly ignore Linux users.
• It’s best to avoid buying new hardware unless it is really needed. Spend saved money on something else (e.g. donation to Free Software Foundation, to developers of your favorite free software product or to any common charity you like).
• Don’t buy a computer without a reset button if you intend to run Linux on it.
• The fact that just presence of two certain drivers in X.Org may cause the whole X server crash and loosing user control over the computer indicates there is something very wrong with software development practices (well, it’s nothing new but the fact proves it’s all not “just fine”).
• Linux doesn’t care about making driver backports easy. Don’t buy new hardware unless you are ready to upgrade everything. Even then you may be forced to apply patches, compile, install, debug, read the source code and make fixes yourself.
• Using kernel modules not included in official Linux kernel is troublesome all the time. I’d abandon using OpenAFS only for this reason if Linux provided any reasonable network file system.
• There is no such thing like reliable driver information. Be ready for a lot of googling, judging and reading the source code yourself.
• I’d be helpless without access to the source code of various components.

In summary, device drivers demonstrate big problems. Hardware vendors are generally uncooperative, there are insufficient resources for reverse engineering and development and documentation of free drivers, software development practices are generally poor. If a device ever becomes reasonably supported, its remaining driver problems are unlikely to get ever fixed once the device vanishes from the market.

I consider device drivers being big blockers of development and adoption of new advanced operating systems. I could tolerate various problems of experimental operating systems, but it’s hard to get any serious interest of new users and developers when the hardware doesn’t work or suffers from big performance problems.

Is there a solution? I can’t see any. Perhaps the only hope may be making coordinated campaigns targeted on hardware vendors and coming of new clever and enthusiastic Linux kernel developers.