Peter Hutterer on the GNOME applet for Wacom tablets

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

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.

Раздельные параметры для каждого устройства в GIMP

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.

Настройка кистевой динамики в GIMP

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 для KDE

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

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

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.

Was it useful? There's more:

19 Responses. Comments closed for this entry.

  1. Highly interesting! Wacom support, or rather configuration, has always been crude on linux. Hopefully we will have an easy to use tool in this new gnome config tool. Artists are most often not overly technical (including myself but I’m struggling along with linux anyways…) so we need easy to use tools and work pipelines.

  2. Very good interview, and much encouragement to Peter Hutterer for his work and the Linuxwacom project.

    As a pro artist on Linux using Wacom, I knew here several period. I learned how to set OLED ( http://www.davidrevoy.com/?article70/set-the-led-display-of-the-wacom-intuos4-tablet-on-ubuntu-linuxmint ) and tweak xsetwacom to follow each change of spec. For binding more action , I also hacked a joypad ( http://www.davidrevoy.com/?article83/gamepad-hack-for-more-button-on-cintiq21ux )
    Lastly with both a Cintiq and a Intuos4 connected + a dual screen with the nvidia driver, I also had hard time ( I’m happy now the twinview mapping works, it was a hell to do transformation matrix math ).

    Thanks also a lot for the very cool wiki of Linuxwacom project : informations are well written. I hope the new xsetwacom settings will be always updated on the wiki :) and -of course- to setup my tablet with this cute GUI in the future :)

    Many thanks for your work.

  3. nice article. id like to say thanks to all the programmers that have worked on the wacom driver and tools. i have been using a wacom intuos table from v2, currently have a v4 with the led buttons. the linux driver has had some rough patches when everything switched over from the old x conf but i could always get something working. i use a wacom on linux at work also(professional). the gui config is probably the most important thing to the users. as it is now most of the config is done by a sysadmin. so you basically get the bare minimum functionality. if we had a user gui config it would be quite radical. i would just like to see this tool not dependent on gnome. there are many studios that run kde. because they have been running kde since before gnome was the big deal it is now. just try to keep that in mind. if we had a command line config that could map some of the setting that would be a step up. lots of studios can not just change there distro and switch to gnome at the drop of a hat.

    I do use gnome on my own box and will try try to test the new tools out. cheers and thanks.

  4. Alexandre Prokoudine 30 September 2011 at 11:29 am

    @Deevad

    Wow, somehow I missed the joypad thing :) I think DIY is a hugely interesting topic.

  5. I see lot of good things for the future. I apreciate all the effort. As a Linux painter and Creator of “Gimp Paint Studio” project, it is very important to have a good “Wacom” experience. So thanks a lot for your work and if i can help you in some way let me know.

  6. In David Revoy picture that program looks like Photoshop, but maybe is Gimp.
    I can’t leave Microsoft, not too many software compatible with Linux…

    Hi Ramon, I saw your youtube videos about Gimp!

  7. @Cabinet Stomatologic

    It’s Krita. That’s what the caption says too :)

  8. I’m using Ubuntu 12.04 and this has the new wacom config GUI for my Intuos4 XL tablet and I can map the buttons on the GUI but nothing seems to be applied, meaning that when I use GIMP 2.8 or MyPaint those mappings are not available/don’t work. So is this tool incomplete or I’m I missing something. I tried going in the #Gnome/#Ubuntu channel on Freenode to ask about it but no one could give me an answer. Can you please ask those Gnome devs to see if I’m missing something or what will it take to make it really work. Right now that thing is useless.

  9. Alexandre Prokoudine 04 May 2012 at 10:30 am

    Hi spartan2276, if you have a look at a more recent coverage here, you’ll see Bastien saying:

    The rough guide is to provide more integration of button mapping with applications, so we could have mappings like “Reduce tip size by 10%” rather than repeating a keyboard shortcut.

    So there is some work planned on that.

  10. Alexandre, that did not answer my question. my question is does the current wacom application work or not. Like I said right now I can add the button mappings to my tablet but there is no way to Apply it as in an “Apply” button or “OK” button to save the changes and actually have it function. So in other words this thing is broken and should not be there, because what is the point of having something that does not work; Unless like I said I’m missing something as is extra software libraries or something else.

  11. Alexandre Prokoudine 04 May 2012 at 5:22 pm

    OK, I asked Bastien, and he said:

    Instant-apply. There’s no need for Save or Apply buttons.
    You need to have gnome-settings-daemon from the same version running. If that doesn’t work, he should file a bug with his distribution.

  12. yes I have that installed, So I guess this does not actually work with Ubuntu 12.04. Software is broken. Thanks!

  13. >>Hi I’m M. Allen West Artist of Embryonicart

    WHY doesn’t this program have a “Disable the TOUCH” button ...

    I had to code one myself using zenity script…


    Example :

    action_1 () {

    zenity—question—text=“Are you sure you want to turn off Touch in Wacom ?”

    xsetwacom—list

    xsetwacom set 12 touch off

    Main

    }

     

  14. Alexandre Prokoudine 18 September 2012 at 7:49 am

    @M. Allen West, because not all features come at once — would be my guess ;-)

  15. Hey Ramon can I get a link to your Youtube Channel?

  16. Is there an official linux-wacom PPA? I know that in the past doctormo was the main repo, but at some stage I was advised against using it.
    I think an official PPA might improve user feedback, I can’t imagine too many artists like fiddling with the CLI to update to the latest drivers?

  17. Alexandre Prokoudine 30 April 2013 at 10:45 am

    Official? Probably no :) There used to be https://launchpad.net/~doctormo/+archive/wacom-plus but i,t has become barely maintained.

  18. Hi Alexandre :)
    Thanks for the response. Yes, that’s the PPA I was referring to and unfortunately also the one I was advised not to use anymore (possibly due to lack of maintenance as noted).
    It’s worth noting that their wiki has some really great documentation on installing/compiling new drivers which I would consider to be a fair enough substitute for an official PPA (for the time being).