I'll be giving a talk next Tuesday, 14 September in Toulouse, France. If you happen to be around that area, more information is available here:
http://www.toulibre.org/
http://www.linuxfr.org/2010/09/07/27352.html
Wednesday, September 8, 2010
Friday, September 3, 2010
Wacom support in Linux
This article should have been written a long long time ago. Anyway, here's the gist of Wacom tablet support under Linux and that hopefully clears up the confusion about the various packages.
linuxwacom is two things. It is the project name used for wacom-specific implementations and thus in the URL as well (in this post, I will always use "linuxwacom project" to refer to the project).
It is also the name of the tarball shipped by the linuxwacom project. Or at least the name of one tarball, anyway. Now, this tarball includes virtually everything linuxwacom as a project wants to provide, most notably a kernel driver, an X driver and several utilities. More on these later.
The main (and long-term) contributor to linuxwacom is still Ping Cheng, a Wacom employee. Wacom naturally has a strong focus on its customers and thus linuxwacom goes into some pains supporting systems all the way back to XFree86-4.
However, the X server has moved quite a bit.
In August 2009, I split out the X11 driver from the linuxwacom package and imported it into a git repository called xf86-input-wacom. This driver has seen quite a bit of rework, including dropping of some features (like XFree86-4 support but also old-style serial tablets) and gaining some features (like input device properties). The driver includes a simple tool called xsetwacom that provides some options to manipulate driver settings at runtime. xsetwacom used to be part of the linuxwacom tarball and I've tried to keep xsetwacom's interface as close to the original as possible.
As of a couple of weeks ago, the xf86-input-wacom driver also includes a simple isdv4-serial-debugger to print information about serial tablets. That's it though, xf86-input-wacom does not contain any other tools.
xf86-input-wacom supports serial devices directly and USB devices provided the kernel supports them. In that regard, it is quite similar to evdev or synaptics - both rely on the kernel for actual hardware support. If your kernel doesn't support a particular device, then xf86-input-wacom won't help.
Note that xf86-input-wacom is the replacement for the linuxwacom X driver, that driver will not compile on X servers 1.7 or later. And the name does not imply that it is for Wacom tablets only, we have code to handle some Waltop tablets and recently added a patch for Fujitsu serial devices. More devices will be added as needed.
The linuxwacom tarball ships with several kernel drivers for various kernel versions. Note that these are out-of-tree drivers and thus if you compile them and then update your kernel, you must recompile and re-install the driver. This out-of-tree development is mostly due to Wacom's commitment to its customers.
Personally I would love to see kernel development happening on LKML only but this is not the case right now. Especially for newer models that support touch the upstream kernel requires the use of the MT protocol, something that the X drivers (neither xf86-input-wacom nor the old linuxwacom one) can handle right now. Especially Bamboos are affected by this. AFAIK, no distribution supports them out-of-the box and users must compile the kernel driver from the linuxwacom tarball. Once that driver is installed, xf86-input-wacom works fine with it.
This is a source of much confusion but while I intended to start working at the kernel drivers, I have enough things on my slate and I have yet to actually do so. Luckily, Henrik and others are working on it.
However, when I read "You may be tempted to download the 0.10.8 version if you have an X server >= 1.7. I tried this, but it did not work. Stick with the production driver, it will work." and (after compiling the kernel driver) "Now, plug in your tablet. It SHOULD be recognized and immediately function as a mouse. " on linux.com I cringed. What happens here is that after the kernel driver from the linuxwacom tarball was installed, xf86-input-wacom automatically picked it up. You need both parts, kernel and X driver.
All these are still available in the linuxwacom tarball. wacdump provides similar functionality to evtest so I don't see the need for maintaining two tools that do the same thing. xidump does the same as xinput --test. Hence both tools are not available anymore on newer distributions.
wacomcpl is a major source of headache. It's a TCL wrapper around xsetwacom to provide a basic graphical configuration utility. It doesn't work anymore due to a number of subtle changes in the xsetwacom interface but also because it partially expects options that don't exist anymore (or in other forms) in the xf86-input-wacom driver. I thought about fixing it up but after looking at it I ran away screaming. I've traded some bugs with Bastien and he'll write a GNOME configuration utility. That's currently holding up on the need for an actual UI (and as engineers we both shouldn't do that one ourselves...) but it will hopefully see the light at some point in the near future. Meanwhile, no GUI configuration tool.
The linuxwacom project is still largely controlled by Wacom, with the exception of xf86-input-wacom that's maintained by me but is heavily contributed to by Ping Cheng, both in patches and code review.
Wacom's internal processes are different to the ones we use in distributions and upstream and that can make life hard for us. (Likewise, our processes make life harder for Wacom so the finger-pointing goes both ways :) Ping and I have had plenty of discussions about this and we try to meet somewhere in the middle where possible, disrupting the project completely helps no-one.
xf86-input-wacom is in a reasonably good state now though the cleanup has taken much longer than expected and there are still several items to be removed or rewritten to fit into the new X server behaviours. I expect this work to take another couple of months but much of it is aimed ad making the driver easier to maintain and develop for. For the average user, it won't have as much impact.
As I said above, I'd like to see kernel development happen on LKML in upstream kernels, not in a separate tarball. This is - aside from the GUI tool - the most pressing issue right now.
As usual, the best way of helping out is to test the code that is available. I'm not a designer so if the tablet doesn't crash the server that's pretty close to 100% functional to me. I rely on others to tell me when behaviours change.
If you're a coder, get right in. If your device doesn't work, go for the upstream kernel and try to get it working there. Anything upstream will feed back into distros and thus improve the out-of-the-box experience. If you have feature-requests for xf86-input-wacom, dig in and write it. The developer's mailing list is useful in any case. Finally, there's the wiki that will eventually be a useful one, but I keep getting distracted with other stuff whenever I try to move info over. So any help there will be useful to others looking for documentation.
And as I pointed out above - we're in desparate need for a UI for the GNOME config utility. If you're interested in helping out here, please contact me.
Finally, I want to point out that Ping (and by inference Wacom Inc.) has been excellent and though we sometimes disagree on technical issues there is no question that Wacom is supportive of the project and their contributions are invaluable.
The role of linuxwacom
linuxwacom is two things. It is the project name used for wacom-specific implementations and thus in the URL as well (in this post, I will always use "linuxwacom project" to refer to the project).
It is also the name of the tarball shipped by the linuxwacom project. Or at least the name of one tarball, anyway. Now, this tarball includes virtually everything linuxwacom as a project wants to provide, most notably a kernel driver, an X driver and several utilities. More on these later.
The main (and long-term) contributor to linuxwacom is still Ping Cheng, a Wacom employee. Wacom naturally has a strong focus on its customers and thus linuxwacom goes into some pains supporting systems all the way back to XFree86-4.
However, the X server has moved quite a bit.
xf86-input-wacom
In August 2009, I split out the X11 driver from the linuxwacom package and imported it into a git repository called xf86-input-wacom. This driver has seen quite a bit of rework, including dropping of some features (like XFree86-4 support but also old-style serial tablets) and gaining some features (like input device properties). The driver includes a simple tool called xsetwacom that provides some options to manipulate driver settings at runtime. xsetwacom used to be part of the linuxwacom tarball and I've tried to keep xsetwacom's interface as close to the original as possible.
As of a couple of weeks ago, the xf86-input-wacom driver also includes a simple isdv4-serial-debugger to print information about serial tablets. That's it though, xf86-input-wacom does not contain any other tools.
xf86-input-wacom supports serial devices directly and USB devices provided the kernel supports them. In that regard, it is quite similar to evdev or synaptics - both rely on the kernel for actual hardware support. If your kernel doesn't support a particular device, then xf86-input-wacom won't help.
Note that xf86-input-wacom is the replacement for the linuxwacom X driver, that driver will not compile on X servers 1.7 or later. And the name does not imply that it is for Wacom tablets only, we have code to handle some Waltop tablets and recently added a patch for Fujitsu serial devices. More devices will be added as needed.
kernel drivers
The linuxwacom tarball ships with several kernel drivers for various kernel versions. Note that these are out-of-tree drivers and thus if you compile them and then update your kernel, you must recompile and re-install the driver. This out-of-tree development is mostly due to Wacom's commitment to its customers.
Personally I would love to see kernel development happening on LKML only but this is not the case right now. Especially for newer models that support touch the upstream kernel requires the use of the MT protocol, something that the X drivers (neither xf86-input-wacom nor the old linuxwacom one) can handle right now. Especially Bamboos are affected by this. AFAIK, no distribution supports them out-of-the box and users must compile the kernel driver from the linuxwacom tarball. Once that driver is installed, xf86-input-wacom works fine with it.
This is a source of much confusion but while I intended to start working at the kernel drivers, I have enough things on my slate and I have yet to actually do so. Luckily, Henrik and others are working on it.
However, when I read "You may be tempted to download the 0.10.8 version if you have an X server >= 1.7. I tried this, but it did not work. Stick with the production driver, it will work." and (after compiling the kernel driver) "Now, plug in your tablet. It SHOULD be recognized and immediately function as a mouse. " on linux.com I cringed. What happens here is that after the kernel driver from the linuxwacom tarball was installed, xf86-input-wacom automatically picked it up. You need both parts, kernel and X driver.
wacdump, wacomcpl, and other tools
All these are still available in the linuxwacom tarball. wacdump provides similar functionality to evtest so I don't see the need for maintaining two tools that do the same thing. xidump does the same as xinput --test. Hence both tools are not available anymore on newer distributions.
wacomcpl is a major source of headache. It's a TCL wrapper around xsetwacom to provide a basic graphical configuration utility. It doesn't work anymore due to a number of subtle changes in the xsetwacom interface but also because it partially expects options that don't exist anymore (or in other forms) in the xf86-input-wacom driver. I thought about fixing it up but after looking at it I ran away screaming. I've traded some bugs with Bastien and he'll write a GNOME configuration utility. That's currently holding up on the need for an actual UI (and as engineers we both shouldn't do that one ourselves...) but it will hopefully see the light at some point in the near future. Meanwhile, no GUI configuration tool.
Future progress
The linuxwacom project is still largely controlled by Wacom, with the exception of xf86-input-wacom that's maintained by me but is heavily contributed to by Ping Cheng, both in patches and code review.
Wacom's internal processes are different to the ones we use in distributions and upstream and that can make life hard for us. (Likewise, our processes make life harder for Wacom so the finger-pointing goes both ways :) Ping and I have had plenty of discussions about this and we try to meet somewhere in the middle where possible, disrupting the project completely helps no-one.
xf86-input-wacom is in a reasonably good state now though the cleanup has taken much longer than expected and there are still several items to be removed or rewritten to fit into the new X server behaviours. I expect this work to take another couple of months but much of it is aimed ad making the driver easier to maintain and develop for. For the average user, it won't have as much impact.
As I said above, I'd like to see kernel development happen on LKML in upstream kernels, not in a separate tarball. This is - aside from the GUI tool - the most pressing issue right now.
How to help
As usual, the best way of helping out is to test the code that is available. I'm not a designer so if the tablet doesn't crash the server that's pretty close to 100% functional to me. I rely on others to tell me when behaviours change.
If you're a coder, get right in. If your device doesn't work, go for the upstream kernel and try to get it working there. Anything upstream will feed back into distros and thus improve the out-of-the-box experience. If you have feature-requests for xf86-input-wacom, dig in and write it. The developer's mailing list is useful in any case. Finally, there's the wiki that will eventually be a useful one, but I keep getting distracted with other stuff whenever I try to move info over. So any help there will be useful to others looking for documentation.
And as I pointed out above - we're in desparate need for a UI for the GNOME config utility. If you're interested in helping out here, please contact me.
Finally, I want to point out that Ping (and by inference Wacom Inc.) has been excellent and though we sometimes disagree on technical issues there is no question that Wacom is supportive of the project and their contributions are invaluable.
XTS census
Tiago's X 1.9 Census includes the commits to the X Test Suite for the 1.9 window. IMO, this isn't particularly expressive since XTS follows its own cycle and the server merge windows have no meaning to it.
The short history of XTS is:
The X Test Suite was written back in the day of yonder (possibly more than two yonks ago) and it is designed to perform a number of protocol tests to verify whether the server has changed behaviour. This includes simple things like creating a window and making sure the MapNotify is sent through to more complex interactions with modifiers and grabs.
XTS was still in CVS until 2009 when I wanted to figure out how much I really broke with MPX. So I imported it into git and started autotooling it. XTS is a bit of a beast and at some point I gave up and asked Dan Nicholson for help; his autotooling skills exceed mine by some unmeasurable amount. A few months later and some 80-something commits later Dan came back with a fully autotooled XTS. So building XTS went from requiring a wiki page to git clone, autogen.sh, make.
From then on, we continued working on making it more sane and easier to run, along with misc code cleanups (DECNET support? Really?) and one of my favourite issues: that after 4 hours of runtime one realised that every test had failed because DISPLAY wasn't set. Anyway, I digress.
We found a couple of issues in the X server as well, with 1.7.7, 1.8.1 and 1.9.0 being the first three releases that pass the test suite without crashing.
XTS is still a bit from being really useful, at the moment many of the test results are write-only (though a few test errors have fed back into the server or even libxcb). Anyway, here are the raw numbers from gitdm (that 1 employer is Unknown because I couldn't be bothered setting up a gitdm.config file).
Note: 1024 of my changesets are a semi-automatic rename of files and that skews the statistic.
The point of this blog post? Give credit to Dan for his magnificent work on XTS because he's been carrying the load for quite a while. And of course, many thanks to Aaron, Jon and Pat for their contributions.
The short history of XTS is:
The X Test Suite was written back in the day of yonder (possibly more than two yonks ago) and it is designed to perform a number of protocol tests to verify whether the server has changed behaviour. This includes simple things like creating a window and making sure the MapNotify is sent through to more complex interactions with modifiers and grabs.
XTS was still in CVS until 2009 when I wanted to figure out how much I really broke with MPX. So I imported it into git and started autotooling it. XTS is a bit of a beast and at some point I gave up and asked Dan Nicholson for help; his autotooling skills exceed mine by some unmeasurable amount. A few months later and some 80-something commits later Dan came back with a fully autotooled XTS. So building XTS went from requiring a wiki page to git clone, autogen.sh, make.
From then on, we continued working on making it more sane and easier to run, along with misc code cleanups (DECNET support? Really?) and one of my favourite issues: that after 4 hours of runtime one realised that every test had failed because DISPLAY wasn't set. Anyway, I digress.
We found a couple of issues in the X server as well, with 1.7.7, 1.8.1 and 1.9.0 being the first three releases that pass the test suite without crashing.
XTS is still a bit from being really useful, at the moment many of the test results are write-only (though a few test errors have fed back into the server or even libxcb). Anyway, here are the raw numbers from gitdm (that 1 employer is Unknown because I couldn't be bothered setting up a gitdm.config file).
Note: 1024 of my changesets are a semi-automatic rename of files and that skews the statistic.
Processed 1275 csets from 5 developers
1 employers found
A total of 33380 lines added, 30758 removed (delta 2622)
Developers with the most changesets
Peter Hutterer 1061 (83.2%)
Dan Nicholson 192 (15.1%)
Aaron Plattner 12 (0.9%)
Jon TURNEY 4 (0.3%)
Tinderbox user 4 (0.3%)
Developers with the most changed lines
Dan Nicholson 20545 (50.0%)
Peter Hutterer 10296 (25.0%)
Aaron Plattner 3854 (9.4%)
Tinderbox user 655 (1.6%)
Jon TURNEY 30 (0.1%)
Developers with the most lines removed
Aaron Plattner 2000 (6.5%)
Developers with the most signoffs (total 5)
Dan Nicholson 3 (60.0%)
Peter Hutterer 2 (40.0%)
Developers with the most reviews (total 10)
Dan Nicholson 7 (70.0%)
Peter Hutterer 3 (30.0%)
Developers with the most test credits (total 1)
Pat Kane 1 (100.0%)
Developers who gave the most tested-by credits (total 1)
Dan Nicholson 1 (100.0%)
The point of this blog post? Give credit to Dan for his magnificent work on XTS because he's been carrying the load for quite a while. And of course, many thanks to Aaron, Jon and Pat for their contributions.
Subscribe to:
Posts (Atom)