GNOME Bugzilla – Bug 786338
Wacom ExpressKey Remote not detected or configurable through gnome-control-center
Last modified: 2021-06-09 16:32:31 UTC
Bug 750745 indicates that it should be possible to configure an ExpressKey Remote by opening the Wacom OSD and selecting the EKR from a dropdown at the top. On my system, at least, this dropdown does not appear. It was suggested that without some "udev rules hackery", this only works if the dongle is plugged into a tablet rather than the system. I tried moving the EKR from my front-panel USB to a port on the side of my Cintiq 24HDT and no observed no change in behavior. libinput-debug-events shows that the EKR is connected and prints events whenever a button is pressed. It also shows that the EKR is in a different "group" than any other tablet on the system, which is perhaps the root cause rather than something in GNOME? Arch Linux GNOME 3.24 with following packages compiled from source: * gnome-settings-daemon-3.24.3 * gnome-shell-3.24.3+2+g34bab377b * gtk3-3.22.17+14+ga30220d4e3-1 * mutter-3.24.4+2+g25f9cdced libinput 1.8.1
Yes, that's the (In reply to Jason Gerecke from comment #0) > Bug 750745 indicates that it should be possible to configure an ExpressKey > Remote by opening the Wacom OSD and selecting the EKR from a dropdown at the > top. On my system, at least, this dropdown does not appear. > > It was suggested that without some "udev rules hackery", this only works if > the dongle is plugged into a tablet rather than the system. I tried moving > the EKR from my front-panel USB to a port on the side of my Cintiq 24HDT and > no observed no change in behavior. > > libinput-debug-events shows that the EKR is connected and prints events > whenever a button is pressed. It also shows that the EKR is in a different > "group" than any other tablet on the system, which is perhaps the root cause > rather than something in GNOME? Yes, I think that is the case. After https://bugzilla.gnome.org/show_bug.cgi?id=750745#c14 Camille and I had a bug assignment session on IRC and we ended up filing https://bugs.freedesktop.org/show_bug.cgi?id=102235 To my understanding, the grouped devices should receive the same LIBINPUT_DEVICE_GROUP udev property, and the same return value through libinput_device_get_device_group().
FWIW, there is now a patch on the fdo bug fixing EKR grouping for the 27QHDT on libinput. I think the 24HDT seems similar treatment. And maybe, looking at the patch, the "plug it on the tablet" detail isn't as important... Just vague memories of how I was told that libinput device groups should "just work" with the EKR.
sorry, I have vague memories that we said it'll work for most cases but need manual setup for others :) we can't get around this, unfortunately. udev doesn't really give us the option to search for other devices and pick the best matching one (afaict), especially since there's no guarantee another device already exists by the time we need this information.
(In reply to Peter Hutterer from comment #3) > sorry, I have vague memories that we said it'll work for most cases but need > manual setup for others :) Mine are vaguer, apparently :). I thought the manual cases would be basically reserved for pairing the EKR with Intuos and other tablets it's really not meant to go with. > > we can't get around this, unfortunately. udev doesn't really give us the > option to search for other devices and pick the best matching one (afaict), > especially since there's no guarantee another device already exists by the > time we need this information. True... I think that sounds like an argument in favor of configurability from the UI.
I guess the only option we have is special-case the 24 and 27 cintiqs and assign them (and their touch devices) the same fixed device group (e.g. "ekr-special-group"). This will break if someone has a set up with two 24/27 in any combination, but I guess that's even more of a niche case.
(In reply to Carlos Garnacho from comment #2) > FWIW, there is now a patch on the fdo bug fixing EKR grouping for the 27QHDT > on libinput. I think the 24HDT seems similar treatment. I should note that the 24 has a pad of its own, so this kind of treatment might not apply. I imagine special-casing would only apply to buttonless display tablets like the 27, the new Cintiq Pro devices, and some DTU tablets. Querying libwacom is advisable... (In reply to Peter Hutterer from comment #5) > I guess the only option we have is special-case the 24 and 27 cintiqs and > assign them (and their touch devices) the same fixed device group (e.g. > "ekr-special-group"). This will break if someone has a set up with two 24/27 > in any combination, but I guess that's even more of a niche case. My own vague memory was that libinput would automagically put an EKR into the same device group as the device it is plugged into. I'd assumed that this magic would be accomplished by having libinput walk the sysfs tree. Wouldn't that be possible here? Its basically the same problem we have to deal with in the kernel and xf86-input-wacom for determining if two devices should be considered "siblings". You can opportunistically add devices to existing groups if the pairing seems plausible at the moment of the hotplug event. (In reply to Carlos Garnacho from comment #4) > True... I think that sounds like an argument in favor of configurability > from the UI. I'm actually wondering if this should be addressed in the Wayland protocol. I suppose its handy to have a reference back to the associated tablet (e.g. for naming), but it seems sensible to either document "NULL" as a value for tablet-less pads or document that compositors should create a placeholder tablet object for the EKR.
(In reply to Jason Gerecke from comment #6) > (In reply to Carlos Garnacho from comment #2) > > FWIW, there is now a patch on the fdo bug fixing EKR grouping for the 27QHDT > > on libinput. I think the 24HDT seems similar treatment. > > I should note that the 24 has a pad of its own, so this kind of treatment > might not apply. I imagine special-casing would only apply to buttonless > display tablets like the 27, the new Cintiq Pro devices, and some DTU > tablets. Querying libwacom is advisable... I shall trust your judgment :). Certainly padless tablets feel a good match for tabletless pads. > > (In reply to Peter Hutterer from comment #5) > > I guess the only option we have is special-case the 24 and 27 cintiqs and > > assign them (and their touch devices) the same fixed device group (e.g. > > "ekr-special-group"). This will break if someone has a set up with two 24/27 > > in any combination, but I guess that's even more of a niche case. > > My own vague memory was that libinput would automagically put an EKR into > the same device group as the device it is plugged into. I'd assumed that > this magic would be accomplished by having libinput walk the sysfs tree. Yeah, that was precisely my recollection too. > > (In reply to Carlos Garnacho from comment #4) > > True... I think that sounds like an argument in favor of configurability > > from the UI. > > I'm actually wondering if this should be addressed in the Wayland protocol. > I suppose its handy to have a reference back to the associated tablet (e.g. > for naming), but it seems sensible to either document "NULL" as a value for > tablet-less pads or document that compositors should create a placeholder > tablet object for the EKR. FWIW, protocol decisions were briefly remembered recently at https://bugzilla.gnome.org/show_bug.cgi?id=779986#c27 and following comments. Perhaps we should document whatever decision we reach this time so we don't stumble on the same rock again :p.
Hi everyone, Krita start to be usable with Wayland... so soon the only thing missing will be the EKR mapping. Any progress on this bug ? Thanks a lot, and have a nice summer !
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.