Peter Hutterer on the GNOME applet for Wacom tablets
With better color management support and a new Wacom configuration applet the newly released GNOME 3.2 looks like a solid improvement for us creative folks.
The interview with Richard Hughes last week was quite long-ish, and I have to admit that the plan to publish a much shorter interview with Petter Hutterer, developer of the Wacom configuration tool, miserably failed as soon as I realized that he is the very same person actively working on the linuxwacom project.
Hence you are getting another full-fledged interview. Read, enjoy, criticize :)
GNOME configuration applet for Wacom tablets
Hi Peter! Could you introduce yourself please? :)
I’m working for Red Hat in the graphics team. Though I’m a bit the odd one out: I’m working only on input, not on graphics. Either way, it keeps me busy. My area includes not only the X Server’s input stack, but also evdev, synaptics and the wacom driver, and to a lesser extent other input drivers.
I’m based in Brisbane, Australia. The advantage is that the weather is much nicer than in most other places I’ve been to before (Let’s pretend the massive floods and the cyclone we had earlier this year were a meteorological slip-up). The disadvantage of living in Brisbane is that I’m in a different timezone than most everyone else, so if you ever ping me on IRC, chances are I am asleep. That’s one of the first things people notice, when they try to talk to me on IRC :)
How did the GNOME configuration tool project start? Was it a push from GNOME design team or just scratching your own itch?
There’s a bit of a back story to it.
The linuxwacom project started many years ago. The CVS history goes back to 2002. Traditionally, the wacom driver tried to provide everything: it included kernel patches, an X input driver, user-space configuration and debugging tools and a graphical configuration tool called wacomcpl.
Two years ago when I started working on the driver, we split out the X input driver into the xf86-input-wacom repository. This split happened mainly because the driver gave me a bit of grief at the time. In the last few years we added a number of features to the X Server but the wacom driver was trailing most of these features.
Take for example input-device hotplugging. The wacom driver is special in that it creates several X input devices off one kernel device — one for the stylus, one for the eraser, and one for each other tool detected. This allows applications like e.g. GIMP to assign different tools and/or colours to each physical device.
Separate settings for Wacom devices in GIMP
Traditionally this was handled by having multiple InputDevice sections in the xorg.conf file that all pointed to the same device file. In a hotplug-capable world, this cannot work — the config backend (previously HAL, now udev) only notifies us once about a new device.
Over a few driver and server releases we integrated hotplugging support into the driver, so now you just plug the device in, and it works. But that left us with another problem: any configuration applied to the device at runtime would simply revert to defaults once the device was unplugged.
The wacomcpl tool I mentioned above stopped working. It only provided runtime configuration, but that isn’t persistent. We could have written a daemon that interacts with wacomcpl, but chose not do so for two reasons: wacomcpl has a number of other design issues, and we already have such a daemon: gnome-settings-daemon.
This is where the integration process started. GNOME already handles all other input devices and applies the configuration as needed. So why not tablets as well?
Interestingly, GNOME also only applies run-time configuration only, but it monitors the device list and re-applies any configuration whenever a new device is plugged in, giving the appearance of persistent configuration (the actual persistent configuration is in gsettings).
So why did we need a new applet?
Having multiple X devices for the same kernel and physical device requires some more knowledge in a configuration UI. For example, if you select to switch the stylus to absolute mode, we also switch the eraser (which is on the same physical pen) to absolute mode. Both the driver and gnome-settings-daemon allow us to use different modes, but I don’t think this is a common use case. So the configuration applet has a bit more knowledge about the driver and the device semantics behind it.
Setting up advanced brush dynamics in GIMP
Plus, the driver supports a lot of configuration options, and many of those see quite some use. So it isn’t just a matter of adding another tab to the mouse configuration panel, I expected that the wacom configuration tool will eventually be quite complex.
The control center applet now provides basic options like choice between absolute and relative modes, left/right-handedness, linear pressure control for eraser and stylus tip and actions for buttons. However it looks like there’s more functionality available that isn’t yet exposed in the user interface. Could you please tell what features exactly those are and what the plan for their implementation is?
Currently, we’re looking at three features: button configuration, calibration and monitor assignment. The wacom driver has rather sophisticated button mapping abilities, and though they are commonly used, they are not configurable through the applet. For example, a common configuration is to have Ctrl+Z mapped to a button on the tablet itself. Pressing that button then triggers Undo in whichever application is currently open. Now, I think that the really correct solution for this is to integrate actions into the toolkit, so that a button can actually be mapped to “Undo”. But for the time being, we need those key sequences as a workaround
Wacom configuration applet for KDE
Calibration is required for on-screen tablets such as the Wacom Cintiq range, but also for those built-in tablets that come with a number of Tablet PCs. However, calibration isn’t unique to graphics tablets, and I’d like to see some shared applet that also works for absolute devices that use different drivers. The evdev driver for example also has basic calibration abilities and could benefit here.
Finally, monitor mapping is a much-requested feature. By default, any absolute device maps to the whole desktop in a multimonitor setup. This is obviously an issue for built-in devices, so we need a way to map those devices to a single monitor only. We have the commandline tools to do that, but nothing in the GUI. Monitor mapping is completely driver-independent, so again we should share the code and the UI for other devices.
The interesting bit about this is that we don’t actually care about monitor mapping as such. The server has a feature to allow any absolute device to map to any area on the screen. So when a user wants to map to e.g. the right monitor, what we do behind the scenes is calculate the offset and dimensions of that monitor in relation to the whole desktop and then map the device to that area.
The current plan is to get all of them done as soon as possible, but reality may interfere with that. On my list all this is slated for Fedora 17, so with a bit of luck everything is done by then. Unless someone intervenes and implements it all before I get to do it myself. I’d be devastated ;)
We have a few more blue-sky goals as well, such as detecting, which type of tablet is connected, and then showing the appropriate configuration options for that tablet. This requires more time and thought than I currently have available.
The name “Wacom Graphics Tablet” sounds a bit vendor specific. On Linux there are more graphic tablets supported, e.g. Genius and, since recently, Hanvon. Does this applet have an abstraction layer to configure other kinds of tablets?
From the X side of things, there are only two drivers that matter for tablets: evdev and wacom. Any simple tablet that only supports a single tool and a few extra axes is handled by evdev. Devices that require the split into multiple X devices use the wacom driver. Because of this split, a generic “Tablet Settings” panel could be a bit complicated since there are some tablets that aren’t handled by the wacom driver.
There is no reason we couldn’t support both types of tablets in the GNOME control center applet, but the applicable settings would be very different, and we don’t have the time right now to handle that. The other option would be, of course, to support simpler tablets through the wacom driver. We can think about that once we see the requests for it. I don’t think we have so far.
As for the actual usage of the name “Wacom”: the first name I gave the applet was just “Wacom Tablet”, and only later it got changed. I just used the name, because the X driver is named wacom (after all, it was created by Wacom Inc.). We do support a variety of tablets now. Wacom, Waltop, some compatible Fujitsu Tablet PCs and, I think, some N-Trig devices too. As far as I know, Wacom Inc. pretty much owns the professional tablet market, so I never bothered to change the driver name from wacom to something more generic. To me, it’s just a name.
My main worry here is that if we rename to just Graphics Tablet, some tablets may not be configurable through it. I’m not really emotionally attached to the current name, so if someone wants to rename it, be my guest.
Coincidentally, most of the above applies to our touchpad driver which is still called “synaptics”, but is now just a generic touchpad driver for touchpads that the kernel can handle.
What does Wacom support look like on Linux today? Do we just plug a tablet in and off we go? No need to restart apps?
For most tablets that is the case, though some of the newest tablets can be unsupported or partially unsupported at any point in time. We don’t get information about the devices until they are released (and a user buys one of them). Chris Bagwell in particular has been doing some great work to make the driver not require updates whenever new hardware comes out, but AFAIK we’re not quite there yet.
Applications don’t need to be restarted unless they only support X Input Extension versions. So I can’t really speak for all applications/toolkits, it really depends. You certainly don’t need to restart the X server anymore for your tablet to work.
How are things going in the linuxwacom project, and what are the current priorities?
The one goal we always have is continuing hardware enablement, but there are a few other features that we’re currently looking at. Eduard Hasenleithner just got the patch for the OLEDs on the Wacom Intuos4 series of tablets merged into the kernel, so we’re working on exposing this to clients through the X driver. These OLEDs are mini-displays that can display bitmaps next to the buttons. Likewise, the status LEDs are worked on by Eduard and Ping Cheng.
OLED in Intuos4, picture courtesy of Wacom Inc.
Jason Gerecke is working on getting a number of features into the xsetwacom CLI tool. His current work aims at matching the features that we had before the split. Before the split, the X input driver supported a lot of features that IMO an input driver should not support (e.g. multimonitor handling). These features got purged early and added back one-by-one. So I readily admit that the driver for a while was less featureful but now we’re almost on-par again. Of course, with a more maintainable codebase and number of other, newer features.
Chris Bagwell is hacking on improving Bamboo support, and that keeps chugging along nicely, both in the kernel and the X driver. Finally, David Foley has been excellent at keeping our wiki in shape and updating it with current information.
One more item that’s on our TODO list but further down the future is a library that would allow applications to get more information about the tablet and its features. Right now this is mostly an idea for future work.
Judging by the old list of changes it was mostly Ping Cheng who did development and maintenance. That was until probably 0.10.x series of versions when half a dozen of people including you became prominent all of a sudden. Did you guys just swim into the focus while having been around for a while, or was it the beginning of a new team?
So the short story here is that the linuxwacom source tree was in CVS, and Ping essentially did code-drops every so-often. The first few patches I did were committed to CVS, but they were, as typical for CVS, giant commits and virtually impossible to pick out again. I got fed up with this quite quickly and forked the driver.
When I did this, I also removed the non-X driver parts because, in my opinion, an X driver repository should contain only the X driver (and related utilities). There was also some duplication in the tree — a tool that was superseded by evtest, another one where xinput has mostly the same functionality, etc.
So the numbers you see are both misleading and correct at the same time. Misleading — because they are inflated — what used to be 1 commit in Ping’s name is now 10 commits in all our names. At the same time, new developers joined or took over more of the work.
I know that Ping Cheng works for Wacom Inc., but the support for Linux was never official. Nevertheless e.g. a new version supporting Bamboo Pen & Touch was released the very next day after announcement by Wacom. Exactly how much assistance do you get from the company?
Ping still works for Wacom Inc., but now she’s mostly on kernel stuff and random backporting projects for customers. Jason is the “new guy” at Wacom and he’s been doing some great work on the X driver. As for the Bamboo support, Chris has done an amazing job, most of the Bamboo code goes on his slate. Not just the X driver, also the kernel driver. I’m not sure if he gets any support from Wacom. I think he was offered some tablets for testing, but I can’t say for sure.
Painting on Wacom Cintiq in Krita, image courtesy by David Revoy
So obviously Wacom has two full-time employees working on Linux support, but they’re also tied up in internal projects that we don’t necessarily see. So Wacom Inc. definitely supports the linuxwacom project. It was initiated by Wacom Inc. after all.
Is there some kind of help you need with either of the projects?
Certainly. I’m quite happy that we’ve managed to build up a small community around the linuxwacom project, but we need more people to test tablets, report issues and help us fix bugs and review patches. The same applies to the GNOME control center applet and the matching bits in gnome-settings-daemon. I’d rather not be in control of those and let others do the work involved there. I’m quite busy with other things too, so anyone who wants to step in is very welcome.
I couldn’t help myself asking this question :) While it’s most likely out of scope for linuxwacom project, do you think it’s possible to get support for Wacom Inkling on Linux in foreseeable future? Can you see someone writing the required software?
To be honest, this is the first time I hear about this product, so I can’t really comment too much on it. From what I can tell from the product page the actual support that’s needed here is the ability to convert the file format that the device provides into something that we can read.
So it is different to the few things we provide at the moment, but it’s not necessarily outside of the scope of the linuxwacom project. We can of course provide hosting facilities and access to the wiki. If there is someone who is working on this and reads this, please ping me, and we can sort something out.
Thank you for your replies!
Chinese translation of this interview is available at LinuxToy.
Patreon subscribers get early access to my posts. If you are feeling generous, you can also make a one-time donation on BuyMeACoffee.
