GNOME Bugzilla – Bug 757483
Wacom tablet buttons "broken"
Last modified: 2021-06-09 16:30:13 UTC
We have a Wacom Intuos 5. It worked fine until today, where the buttons simply stopped working. They had action attached to them, like switch screen, which does not perform. Instead I notice that it seems like the top button performs as a middle click (for instance it paste highlighted texts), and the second top button as a right click. If I go in the Wacom tablet settings, the tablet is perfectly seen, I can still affect various settings (like which screen it works on, etc.) but when mapping buttons, clicking on any button does not display the menu to choose a new action associated to the button. Note that the actions currently displayed are still the right one which I configured some time ago (even though they don't perform, as said above, and I can't change them). I have tried to plug the tablet on another computer, with the same software installed (Fedora 22, with GNOME 3.16.4), all up to date (I don't know how to check exact differences, what I know if that they are both said up-to-date by dnf), and tried to reproduce the issue. I was not able to reproduce it: it worked perfectly as it used to on the first computer. At least it means that the hardware is not the issue here. This is a very problematic issue since we works with graphics daily. So we would appreciate some help. :-) Below the output of dmesg when I plug the tablet: [ 1840.730865] usb 1-9: new full-speed USB device number 12 using xhci_hcd [ 1840.897320] usb 1-9: New USB device found, idVendor=056a, idProduct=0027 [ 1840.897327] usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 1840.897331] usb 1-9: Product: Intuos5 touch M [ 1840.897335] usb 1-9: Manufacturer: Wacom Co.,Ltd. [ 1840.901206] input: Wacom Intuos5 touch M Pen as /devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.0/0003:056A:0027.000B/input/input46 [ 1840.901858] input: Wacom Intuos5 touch M Pad as /devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.0/0003:056A:0027.000B/input/input48 And the input of `journalctl --boot |grep -i 'wacom\|usb'`: Nov 02 15:36:01 WhiteDochi kernel: usb 1-9: new full-speed USB device number 14 using xhci_hcd Nov 02 15:36:01 WhiteDochi kernel: usb 1-9: New USB device found, idVendor=056a, idProduct=0027 Nov 02 15:36:01 WhiteDochi kernel: usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Nov 02 15:36:01 WhiteDochi kernel: usb 1-9: Product: Intuos5 touch M Nov 02 15:36:01 WhiteDochi kernel: usb 1-9: Manufacturer: Wacom Co.,Ltd. Nov 02 15:36:01 WhiteDochi kernel: input: Wacom Intuos5 touch M Pen as /devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.0/0003:056A:0027.000F/input/input58 Nov 02 15:36:01 WhiteDochi kernel: input: Wacom Intuos5 touch M Pad as /devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.0/0003:056A:0027.000F/input/input60 Nov 02 15:36:06 WhiteDochi kernel: wacom 0003:056A:0027.000F: hidraw2: USB HID v1.10 Mouse [Wacom Co.,Ltd. Intuos5 touch M] on usb-0000:00:14.0-9/input0 Nov 02 15:36:06 WhiteDochi kernel: input: Wacom Intuos5 touch M Finger as /devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.1/0003:056A:0027.0010/input/input62 Nov 02 15:36:06 WhiteDochi kernel: wacom 0003:056A:0027.0010: hidraw3: USB HID v1.10 Device [Wacom Co.,Ltd. Intuos5 touch M] on usb-0000:00:14.0-9/input1 Nov 02 15:36:06 WhiteDochi mtp-probe[4792]: checking bus 1, device 14: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-9" Nov 02 15:36:06 WhiteDochi /usr/libexec/gdm-x-session[1673]: (II) config/udev: Adding input device Wacom Intuos5 touch M Finger (/dev/input/mouse2) Nov 02 15:36:06 WhiteDochi /usr/libexec/gdm-x-session[2044]: (II) config/udev: Adding input device Wacom Intuos5 touch M Finger (/dev/input/mouse2) Nov 02 15:36:06 WhiteDochi /usr/libexec/gdm-x-session[2044]: (II) config/udev: Adding input device Wacom Intuos5 touch M Pen (/dev/input/mouse1) Nov 02 15:36:06 WhiteDochi /usr/libexec/gdm-x-session[1673]: (II) config/udev: Adding input device Wacom Intuos5 touch M Pen (/dev/input/mouse1)
(In reply to Jehan from comment #0) > We have a Wacom Intuos 5. > > It worked fine until today, where the buttons simply stopped working. What did you change then? If it worked and doesn't anymore, something broke. Is gnome-settings-daemon still running? Did it crash?
> What did you change then? If it worked and doesn't anymore, something broke. Indeed. That's just the thing, we can't figure out. Actually I may have been wrong when I said that it worked fine until today. It turns out that the tablet user (it's not me) does not use the tablet buttons that often (she uses the tablet itself daily though), since she has her second hand on the keyboard rather than on the tablet. She only noticed it today because the tablet was suddenly not mapped onto the right screen when she logged (why did it change? Is it related to the button issue? No idea either) and she tried to switch but the button where the function had been mapped failed to work. That's how we discovered. Since usually the tablet is always mapped on the right screen (the big expensive one where she paints), she does not have to hit tablet buttons much and she is not sure how many days she has not used them. And since we regularly install the updates and Fedora has quite a lot of these, it would be hard to find if it comes from a package update (I tried). > Is gnome-settings-daemon still running? Did it crash? Looks like it's running: > $ ps -ef |grep settings > gdm 1703 1686 0 15:01 tty1 00:00:00 /usr/libexec/gnome-settings-daemon > aryeom 2241 2147 0 15:02 tty2 00:00:02 /usr/libexec/gnome-settings-daemon > aryeom 6479 6028 0 16:20 pts/0 00:00:00 grep --color=auto settings
(In reply to Jehan from comment #0) > We have a Wacom Intuos 5. > > It worked fine until today, where the buttons simply stopped working. They > had action attached to them, like switch screen, which does not perform. > Instead I notice that it seems like the top button performs as a middle > click (for instance it paste highlighted texts), and the second top button > as a right click. Hmm, it looks like g-s-d is losing the passive grab on the tablet buttons, or not taking it at all. It should be doing that with every "pad" device it finds, could you paste/attach the output of "xinput list-props <pad-device-id>", you'll be able to find out the pad device ID with "xinput list".
$ xinput list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ TypeMatrix.com USB Keyboard id=10 [slave pointer (2)] ⎜ ↳ ImPS/2 Generic Wheel Mouse id=14 [slave pointer (2)] ⎜ ↳ Wacom Intuos5 touch M Pad pad id=8 [slave pointer (2)] ⎜ ↳ Wacom Intuos5 touch M Finger id=11 [slave pointer (2)] ⎜ ↳ Wacom Intuos5 touch M Pen stylus id=12 [slave pointer (2)] ⎜ ↳ Wacom Intuos5 touch M Pen eraser id=13 [slave pointer (2)] ⎜ ↳ Wacom Intuos5 touch M Pen cursor id=15 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Power Button id=7 [slave keyboard (3)] ↳ TypeMatrix.com USB Keyboard id=9 [slave keyboard (3)] ↳ Microsoft® LifeCam HD-5000 id=16 [slave keyboard (3)] $ xinput list-props 8 Device 'Wacom Intuos5 touch M Pad pad': Device Enabled (148): 1 Coordinate Transformation Matrix (150): 0.600000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 Device Accel Profile (277): 0 Device Accel Constant Deceleration (278): 1.000000 Device Accel Adaptive Deceleration (279): 1.000000 Device Accel Velocity Scaling (280): 10.000000 Device Node (268): "/dev/input/event18" Wacom Serial IDs (294): 39, -1, 15, 0, 0 Wacom Serial ID binding (295): 0 Wacom Pressure Threshold (296): 0 Wacom Sample and Suppress (297): 2, 4 Wacom Enable Touch (298): 1 Wacom Enable Touch Gesture (300): 0 Wacom Touch Gesture Parameters (301): 0, 0, 250 Wacom Tool Type (302): "PAD" (311)
The more I think about this, the more of a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=749767 that it looks to me... the ordering at which the devices are added matter, so it looks to me like this could happen if the pad happens to be left unconfigured.
Bug 749767 is fixed so there's a patch to test.
(In reply to Bastien Nocera from comment #6) > Bug 749767 is fixed so there's a patch to test. I've found this same bug while I'm working on a patch for ExpressKey Remote support. I've found that if I do a clean install of F22, then do a dnf update and restart, that I can trigger this bug (with multiple tablets models). I've also seen the bug on F23 on a different machine. I've tested the patch at Bug 749767 and that didn't resolve the issue. (In reply to Carlos Garnacho from comment #3) > Hmm, it looks like g-s-d is losing the passive grab on the tablet buttons, > or not taking it at all. > Checking with xev I see that X shows ButtonPress events. Where in the code should the grab be taking place?
(In reply to Aaron Skomra from comment #7) > (In reply to Bastien Nocera from comment #6) > > Bug 749767 is fixed so there's a patch to test. > > I've found this same bug while I'm working on a patch for ExpressKey Remote > support. I've found that if I do a clean install of F22, then do a dnf > update and restart, that I can trigger this bug (with multiple tablets > models). I've also seen the bug on F23 on a different machine. > > I've tested the patch at Bug 749767 and that didn't resolve the issue. > > (In reply to Carlos Garnacho from comment #3) > > > Hmm, it looks like g-s-d is losing the passive grab on the tablet buttons, > > or not taking it at all. > > > Checking with xev I see that X shows ButtonPress events. Where in the code > should the grab be taking place? It happens at https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/wacom/gsd-wacom-manager.c#n833 , that set_wacom_settings() function is basically called for every device we can create a GsdWacomDevice from, and grab_button() is defined at https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/common/gsd-keygrab.c#n36 , which grabs on XIAnyButton.
Is there still a question pending? Please let me know if all info is here or more needs to be added. Otherwise, could this bug be moved away from NEEDINFO to NEW or ASSIGNED or whatever is appropriate?
(In reply to Pander from comment #9) > Is there still a question pending? Please let me know if all info is here or > more needs to be added. Otherwise, could this bug be moved away from > NEEDINFO to NEW or ASSIGNED or whatever is appropriate? The original reporter still needs to test the patch in bug 749767.
Sorry, I didn't realize I needed to test a patch. Do you know if there is a Fedora 23 package which includes this patch, or do I have to build the gnome-settings-daemon from git repo?
I have no idea. I am using Ubuntu and am willing to do additional test if there are packages somewhere to test with.
Looks like the patch from bug 749767 should be included in gnome-settings-daemon 3.18.2. That version should already be available in A Fedora 23 (if I understand correctly -- check yum to be sure), or a build found at http://koji.fedoraproject.org/koji/buildinfo?buildID=698347 It looks like Ubuntu only has 3.16.3, but maybe there is a PPA out there somewhere.
Meanwhile we are at gnome-settings-daemon version 3.22.1-0ubuntu1. What is needed (as this bug is flagged NEEDINFO) in order to move fixing of this bug further?
What is the current status (with regard to that bugzilla is replaced with github)?
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new bug report at https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/ Thank you for your understanding and your help.