The Wacom Tablet Adventure

So my big present for Christmas this year was a Wacom tablet… I had asked for this knowing it might be a challenge to get it working on my two Linux systems, let alone doing something useful… And while I’ve dabbled with modeling in Blender (and creating textures and other graphics in GIMP) it’s not something I do quite enough of that I felt sure I really needed a $200 input device to do it better… But now that it’s up and running I think it’ll be a great piece of gear for me, and I look forward to learning to use it better. I wanted to write this post largely so that if anybody else found themselves facing similar technical difficulties, they’d be able to find this posting and get some guidance.

This post is time stamped in WordPress, of course, but just in case, this was all happening in the last week of December, 2010. I was running Debian stable (“lenny”) on a EEE 901, kernel version If you’re reading this five years later, the information here is probably outdated…  But then again, maybe not?  I’m looking forward to those hoverboards you’ve got, BTW.

The tablet I got is called the “Bamboo Fun” or “Bamboo Fun & Touch”. Actually this particular model goes by a few different designations, which was actually one of the challenges in figuring out why it didn’t work initially… The source code for the Linux Wacom driver calls it “Wacom Bamboo Comic 2FG” – and the device itself has the model number “CTH-661” printed on the back – anyway, it’s a medium-sized tablet with pressure sensitivity but no tilt, four buttons, and a multi-touch sensor.
So first thing I did was try plugging it in and seeing if it worked. It didn’t. This was slightly confusing because the version of the Wacom driver I was using (the stock one that comes with Linux 2.6.26) says it supports the Wacom “Bamboo Fun”. But I did the config and plugged in the tablet and got nothing. I tried monitoring events with xinput and directly using wacdump on various files in /dev/input… I wasn’t sure at this point if something was wrong with my config, or if my software didn’t support the tablet – I didn’t know what I’d have to do to fix the situation, or even if support existed in the Linux Wacom driver for my tablet.
Early on I noticed that plugging in and unplugging the tablet didn’t result in an input device being created or destroyed in /dev/input/ – so that was a big clue that the Wacom driver simply wasn’t working for my tablet. But the important question was why. To answer that, I used lsusb to find the tablet:

Bus 003 Device 002: ID 056a:00d8 Wacom Co., Ltd

Those numbers after “ID” are the USB device’s vendor and product IDs. Those IDs are intended to uniquely identify the type of a USB device so that driver software on the host computer can claim devices it knows how to talk to. The vendor ID, “056a” identifies the device as a Wacom item, while “d8” identifies what particular Wacom item it is.
The first stop was the kernel source. It seemed the kernel driver didn’t support this tablet but I wanted to be sure. I found the driver in /usr/src/linux/drivers/input/tablet – the specific file of interest, as it turned out, was wacom_wac.c. I needed to find the place in the driver containing the product IDs of the supported devices. Scrolling down I found two different sections of interest:

static const struct wacom_features wacom_features_0x18 =
        { "Wacom BambooFun 6x8",  WACOM_PKGLEN_BBFUN,     21648, 13530,  511, 63, WACOM_MO };
        { USB_DEVICE_WACOM(0x18) },
        { USB_DEVICE_WACOM(0x19) },

The “USB_DEVICE_WACOM” stuff is the list of all the USB devices supported by the driver. (My device, 0xD8, wasn’t on it.) The “wacom_features” struct is part of a data table identifying the properties of each tablet listed in the device ID table. It was no shock to find my tablet wasn’t on the list – but it was good to have that confirmed, and I now knew what to look for, to make sure a newer version of the driver supported the tablet before going to the trouble of compiling it.
So the next stop was The Linux Wacom Project to see if they had a newer driver available and if it would support my tablet. Because there’s so many regional variants of the product names it was damn near impossible to tell from a change log, etc. whether my device was supported. So I downloaded the latest version of their kernel driver (0.10.10-1), linked from the main page. The package includes source directories for two different versions of the kernel: 2.6.30 (through 2.6.35, presumably) and 2.6.36 (and onward). I checked the copy of wacom_wac.c in the 2.6.36 directory and was pleased to find my tablet (0xD8) listed. (But as “Bamboo Comic 2FG”? WTF? I guess it’s too much to ask that Wacom pick a product name and stick with it…)
The archive didn’t seem to include a version for the kernel I was already running (2.6.26) so it seemed like a kernel upgrade was going to be necessary. Apart from the fact that this task would take a long time on my laptop (being an Atom-powered lightweight) I wasn’t looking forward to it, but I felt it was about time for a kernel upgrade anyway.
So I got the kernel source (2.6.36’s copy of the Wacom driver didn’t include my tablet, so I had to copy it in) and built the thing. Rebooting into the new kernel gave me a bit of trouble ’cause I haven’t done it in a while (I’m still not used to Debian’s way of handling kernels – the kernel is always loaded with an “initramfs” containing all the kernel modules – and then later in the boot process the initramfs is discarded and the real root fs is mounted.. I forgot to provide an initramfs image, and my boot menu configuration didn’t give me the opportunity to boot the older kernel image – so my first attempt failed and actually made the machine unbootable. I actually had to boot off a USB stick to fix the problem…) Once I finally booted into the new kernel, plugging in the tablet created a device file in /dev/input, as well as the expected symlink /dev/input/wacom. And wacdump worked, too! So that was good news.
However, the tablet still didn’t work in X. Or rather it did, but only as a mouse. The xinput devices I’d set up for it in xorg.conf didn’t work, no data came out of them. So it seemed I was going to have to upgrade the input driver for X as well. Looking at the Linux Wacom site again, it seemed the updated X driver was going to depend on a newer version of – version 1.7. Looking at the package xserver-xorg-core, the version in Debian Lenny was just 1.4.2. I wasn’t about to try compiling on my laptop, so to get the updated version of X I switched apt to get packages from Debian “unstable” (Debian “testing” would have worked as well). In addition to the X input driver source from Linux Wacom, I needed the package “xserver-xorg-dev“, containing the header files and such necessary to build an xinput driver from source. I also installed “xserver-xorg-input-wacom” – it didn’t work with my tablet, so I still had to rebuild it from source, but the Debian package included a configuration file, (/usr/share/X11/xorg.conf.d/20-wacom.conf) that could detect when a Wacom tablet was attached and set up the xinput devices accordingly. Once I realized this i commented out my changes to xorg.conf
Debian upgrades are always a bit traumatic in my experience, because so much changes all at once. But this one actually went quite well for the most part. After the upgrade, a few features like on-screen displays for the volume control keys and such (which hadn’t worked before) now worked… So I built and installed the Wacom xinput driver – and finally, it worked! It still amazes me what a difference a tablet can make when working in GIMP. GIMP allows you to assign different aspects of the stylus (like pressure or velocity) to different traits of the tool you’re using: you can scale your brush, vary opacity or color, and so on. It’s incredible what a difference that extra bit of control can do: suddenly it was almost like smearing paint around.
So, mission accomplished! I was now able to use my Wacom tablet as a regular pointing device, and I could also draw with it (with pressure sensitivity), use the eraser as a separate tool, etc. However, somehow the upgrade had caused some problems on my system: I first discovered this when running on battery power, and plugging the laptop in: the screen went black and the laptop went unresponsive. I discovered that it also did this if I closed the machine, or even if I ran “pm-suspend” at the command line. This baffled me for a while and I briefly just worked around it. But then it started doing the black-screen crash on bootup as well.
This put me in an awkward position. I couldn’t boot into my new kernel (2.6.36) because it would crash before I could log in. I could boot into my old kernel (2.6.26) – however, the new versions of X and my wireless card drivers didn’t work in that kernel version – and I don’t know how to connect to a wireless access point in Linux without using gnome-network-manager anyway, so the only way I could access the network on that machine (to install packages, etc.) at that point was via ethernet cable. For a while I thought some mysterious failure might have occurred in the process of building my new kernel – but I couldn’t think of why that would happen, and didn’t want to go through the hours-long procedure of building the kernel again just on an unsubstantiated hunch that something was wrong with it… But for a short while it seemed like the kernel was the culprit: for some reason all my ACPI-related stuff was causing that crash, and only (apparently) in that one kernel that I’d built… Except, as it turned out, the crash also occurred in a 2.6.32 kernel I’d installed from Debian. It was clearly ACPI-related so I rebooted into 2.6.26 and removed all the ACPI stuff, then went back to 2.6.36 and reinstalled it again… Things seemed to work, but then I rebooted and it crashed again. Finally, by experimentation I discovered that it was one specific ACPI scripts package, “eeepc-acpi-scripts” that was causing the problem. I removed that package and all the ACPI features continued to work with the exception of a couple hotkeys I never use (the unlabeled user-configurable keys, which “eeepc-acpi-scripts” had bound to “turn off webcam” and “turn on/off bluetooth”) – but the crashes went away. So “eeepc-acpi-scripts” = evil. Maybe at some point the package was a good thing, but at this point it clearly conflicts quite badly with something, and so now, therefore, it is evil.
So now all appears to be well… Which is good, because those ACPI crashes were really frustrating…  I still don’t know what exactly was causing those crashes, but it’s fixed now, and my laptop’s running better than ever.  Plus there’s the tablet.  I’ve got a tablet now.  Tablets are cool.
Incidentally, a few days ago Linux version 2.6.37 was released. It includes the updated Wacom kernel driver, which will make things easier when I finally get the tablet working on my desktop machine.

Post a Comment