The names of action atoms are currently created without regard to
the property they will be stored in. This results in both e.g.
button 1 and StripLeftUp using atoms with the name Wacom button
action 1. When setting either button 1 or StripLeftUp, we ask
the server for an atom named Wacom button
Thanks for the quick response.
I tried the patch. It does not appear to solve the issue. I
tried the same test case as before:
$ xsetwacom --set Wacom Intuos3 6x8 pad StripLeftUp key +g -g
$ xsetwacom --get Wacom Intuos3 6x8 pad StripLeftUp
key +g -g
$ xsetwacom --set Wacom Intuos3 6x8 pad
Could you provide the output of xinput list-props id after running
your test case (id will be the numeric ID of Wacom Intuos3 6x8 pad
displayed in xsetwacom list)? It sounds like the new naming scheme
hasn't overwritten the old one. So far I've only been able to trigger
this behavior if the old
Ah of course. I should have thought of that, but I'm not used to
fiddling with drivers and modules. (I even spent a few minutes making
doubly sure that I had recompiled after patching and was running the
patched version, but for some reason I didn't think about the drivers)
After unplugging,
