Making the Trust 1200 Wireless tablet work on Linux

I have gotten access to an old wireless tablet ("wireless" as in the pen is battery powered, tablet is wired USB), and have gotten it work. Since it was not trivial to figure out how to do that, I though I would describe the steps.

First the context: in the old days, X11 communicated directly with the hardware. So for a tablet to work, there needed to exist an X11 driver. There seem to be 2 kinds of tablets: Wacom tablets and non-Wacom tablets, with Wacom tablets generally having much better Linux support. So the first thing I found was some X11 Wizardpen drivers which had not been updated since 2011, which supposedly supported various non-Wacom tablets. This was very much a blind alley.

After some further investigation, I found that in the newer Wayland architecture, tablet drivers had been moved into the kernel, and the Wayland project libinput had been created as a middle layer. And in fact the DIGImend project had already created a driver for my tablet (which turned out to be a rebranded AIPTEK), which was already in my Fedora installation. The output from the usb-devices command showed a device with "Product=USB Tablet Series Version 1.04" and "Driver=aiptek", and from the dmesg output:

[   52.555422] aiptek 1-1:1.0: Aiptek using 400 ms programming speed
[   52.555613] input: Aiptek as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/input/input16
[   52.556200] usbcore: registered new interface driver aiptek

Indeed, doing cat /dev/input/event16 showed output when I interacted with the tablet, so the kernel driver appeared to be forwarding output from the tablet. Now, my tablet was still not showing up in GIMP's list of input devices. Fedora uses Wayland, and GIMP is an X11 app, so GIMP is running via XWayland (X server on top of wayland), but as I could read newer X implementations should still use Wayland's libinput for tablet support.

Rather obscurely, and after much random poking, I noticed that when running the libinput list-devices command, the following was printed to stderr:

event16 - Aiptek: libinput bug: missing tablet capabilities: resolution. Ignoring this device.

It would have been much, much more user friendly if this kind of error message was in the gnome control panel list of input devices, or the gimp list of input devices. Instead both places simply had nothing, initially leaving me wondering if my tablet was working at all.

So it turns out that the libinput tablet support needs to know various information, including in this case the resolution (pixels/mm) of the tablet, in order to work. And while I could see from the output of evemu-describe /dev/input/event16 that libinput had figured out e.g. the total number of vertical and horizontal pixels (presumably the tablet has some kind of hardware information protocol), the resolution was indeed missing. So now that I knew what to google for, I found and followed the instructions written by Peter Hutterer in freedesktop.org bugs 100043 and 103476 to add a HWDB entry to my system with the resolution of my tablet.

The database of tablet hardware information is at /usr/lib/udev/hwdb.d/60-evdev.hwdb, and the top of that file has some basic instructions for how to add new entries. It recommends to add new entries for the local system to /etc/udev/hwdb.d/61-evdev-local.hwdb. The entry I added there to make my tablet work was the following:

#########################################
# Trust (AIPTEK)
#########################################

#TRUST 1200 Wireless Tablet
evdev:input:b0003v08CAp0010*
 EVDEV_ABS_00=::20
 EVDEV_ABS_01=::20

The first non-comment line (evdev:input:b0003v08CAp0010*) is to match the device (and only that device). The EVDEV_ABS_00 is configuration for the X axis, and EVDEV_ABS_01 is configuration for the Y axis. The fields in the X/Y configuration have the format EVDEV_ABS_<axis>=<min>:<max>:<res>:<fuzz>:<flat>. I only want to set the "res" field, so I leave the first two fields and the last fields unchanged by doing "::20".

The resolution of 20 pixels/mm I figured out the output of evemu-describe

[...]
#   Event type 3 (EV_ABS)
#     Event code 0 (ABS_X)
#       Value     4658
#       Min          0
#       Max       5999
#       Fuzz         0
#       Flat         0
#       Resolution  20
#     Event code 1 (ABS_Y)
#       Value     1807
#       Min          0
#       Max       4499
#       Fuzz         0
#       Flat         0
#       Resolution  20
[...]

(the "Resolution 20" only appears because I already manually added it before writing this) and from simply measuring the tablet size (the size was also mentioned on the box the tablet came in). So e.g. for the X axis, there are 6000 pixels and the tablet is 12 inch*(25.4mm/inch) wide, so the resolution is 6000/(25.4*12)=19.7pixels/mm. According to the comments by Hutterer in the freedesktop.org bug reports, the resolution should be an integer, so 19.7 should be rounded to the nearest integer. Similarly, the vertical resolution turns out to be 4500/(25.4*9)=20pixels/mm.

In the match string (evdev:input:b0003v08CAp0010*), the "b" stands for "bus", the "v" stands for "vendor", and the "p" stands for "product". The USB bus is 0003, and the b and v can be figured out from the output of the usb-devices command:

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=1.5 MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=08ca ProdID=0010 Rev=01.03
S:  Manufacturer=AIPTEK International Inc.
S:  Product=USB Tablet Series Version 1.04
C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=26mA
I:  If#=0x0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=aiptek

So having finally added that entry, I could run

   systemd-hwdb update
   udevadm trigger /dev/input/event*

to tell the system about the new entry, and my tablet was available in the GIMP input devices configuration.

Of course I then created a pull request to the systemd github repository, which manages the HWDB, so the tablet could also work for other people. Having done that, it turned out that the automated test run on my pull request found a duplicate match line in the hardware database, and that somebody else had already added information for my tablet in the newest version of systemd. Argh - that is some coincidence, because there are only about 94 entries in that file, and my tablet is ancient. But I hope that this blog entry can still be helpful as a description for other people.