#269 xsetwacom doesn't like modifiers

[Torpak]

Hi, i am using xsetwacom version 0.27.0-1 under Arch linux.
I tried setting some of the Buttons on my Wacom Intuos Pro M to emit ctrl alt and shift.
This gave me the following:
$ xsetwacom --set 18 Button 1 "key ctrl"
Warning: unable to map 'Control_L' to a keycode.

The result is the same for all modifier keys i tried.

Even with other keys like in the examples:

$ xsetwacom --set 18 Button 1 "key +shift a -shift"
Warning: unable to map 'Shift_L' to a keycode.
Warning: unable to map 'Shift_L' to a keycode.

I wouldn't even bother with xsetwacom but the kde graphics tablet setting can't do it either (maybe it uses xsetwacom internaly).
Is there any workaround?

[Torpak]

Is there maybe a way to tell xsetwacom directly to use keycode 37?

[Jason Gerecke]

That's very strange. That message would normally be generated if your keyboard does not have the requested key on it. You might try using "key Control_R" or "key Shift_R", but the lack of their left-handed brethren doesn't give me much hope for that working. Just for kicks, could you run xmodmap -pk and attach the output?

The xsetwacom tool can't be told to use specific keycodes, but you can modify the raw properties with xinput. The following command is equivalent:

xinput set-int-prop 18 "Wacom button action 0" 32 1114149

The "Wacom button action 0" indicates that this is for the first physical button on the tablet, while the "32" indicates a 32-bit property, and "1114149" is the code for "press keycode 37". (The "AC_" bits at the bottom of Xwacom.h define its format)

[Torpak]

Hi, i tried your xsetinput line and it works like a charm.
Could you give me a second hint how to calculate the 1114149 from 37? I assume some bitwise OR but of which values exactly?
I attached the output of xmodmap -pk as you requested.
Btw. i had already tested Control_R and Shift_R with the same result.
Thank you for your quick reply!

[Torpak]

is it just 0x110000 and 0x000025?

[Jason Gerecke]

That's correct. As I mentioned above, the Xwacom.h file describes the structure, but basically "0x0011ABCD" signifies a keypress of the keycode 0xABCD (clearing its highest '1' will make it a keyrelease). You can list up to 255 actions to do things, to do e.g.:

$ xinput set-int-prop 18 "Wacom button action 0" 32 1114149 1114166 65590 65573
$ xsetwacom get 18 button 1
key +Control_L +c -c -Control_L

[Torpak]

Interestingly this way around it works at my system the same as yours.
So xsetwacom get is not affected by the error.
Do you use a different table for the backwards translation?

[Torpak]

Nice! So if the bugfix takes a little longer i can cook up a workaround easily.
Thank you again! :-)

[Torpak]

Hi i just found out that i made a mistake:
While the problem (not setting modifier keys) exists with 0.27.0-1,
i only get the above warning with xf86-input-wacom-git which identifies itself as 0.27.99.
Hope that helps finding the bug. (or finding out what i did wrong ;-)

[Jason Gerecke]

The warning you see was added to xsetwacom for this latest release after getting feedback that it hadn't been providing any indication that things were going awry. Typically it would be triggered if you tried to have xsetwacom press a key that wasn't in your keymap, but in your particular case the key does exist and xsetwacom isn't finding it for whatever reason. I'll take a closer look at the responsible function and see if there's any subtle bugs.

Would you be okay with applying some test patches and compiling/installing from source if necessary?

[Torpak]

No Problem! I would be more than happy too.
Thank you very much for looking into this so soon!
:-)

[Jason Gerecke]

The same table is used in both 'get' and 'set' codepaths, which is even stronger evidence that we're skipping valid entries. Oddly, our 'get' is done more lazily than our 'set', so if anything I'd expect the opposite situation :D

Comparing the two, the only thing that makes sense is that some keys on your keyboard are spread across multiple "groups" and that for whatever reason the server reports that you're in a group other than number 0. I should have a patch for you to test out by tomorrow.

[Torpak]

I don't know much about keyboard mappings (seems like dark magic to me).
I'm using dvorak keyboard layout which as far as i know not too many people
do. Could it be possible that this is causing my problems?
Or is that a totally different layer?
Whatever the cause i will gladly test your patch tomorrow or any other day
this week :-)

[Torpak]

Well at least switching to german keyboard layout didn't fix the problem.
(it was worth a try anyway ;-) )

[Jason Gerecke]

I've attached a patch which should provide me with the necessary debugging information to understand what's going on. Please apply it, recompile/reinstall, and then run the following command and attach the created file for analysis:

xsetwacom --verbose --set 18 Button 1 "key ctrl" 2> /tmp/output.log

[Torpak]

I attached the log file.
While there is no warning in the file or on stderr, it does not work. (i didn't expect it to since this was a debug patch but tell you just for completeness sake)

[Jason Gerecke]

Are you sure it didn't work? The final line of the log reads "... Key map 65507 (37, 'Control_L') [press,]" which indicates that it was able to find the Control_L key at keycode 37 like we expect.

As for the reason the key wasn't found earlier, I think I understand why. Your keyboard layout has both a German "group" and a Dvorak "group" defined. After receiving a keycode (e.g. 24), the active group is consulted to determine which keysym it corresponds to (e.g. 'q' or 'apostrophe'). The problem is that groups other than the first are free to leave keys undefined; in particular, the Dvorak group on your layout doesn't define things like Control and Shift. There are rules on what to do in such an instance, but xsetwacom isnt' aware of them and so failed when it shouldn't have.

I've attached another patch to apply which adds the necessary logic to xsetwacom. Give it a try and let me know what happens. If it doesn't work, attach a new output.log for me.

[Jason Gerecke]

Whoops -- forgot to actually attach the patch!

[Torpak]

This patch works like a charm!
Even the kde tablet settings work correctly now. That seems to support my theory of it using xsetwacom internally.
Thank you very very much for your work and for the interesting information!

[Jason Gerecke]

• Fix accepted into xf86-input-wacom on the "master" branch (commit 27b713e). Expected release: xf86-input-wacom 0.29.0.

[Jason Gerecke]

• Fix released in xf86-input-wacom-0.29.0