GNOME Bugzilla – Bug 722437
Show OSD if capslock is being pressed on keyboards with no leds
Last modified: 2021-07-05 14:09:20 UTC
keyboards with no leds to indicate *lock state are somewhat confusing currently, as eg. you can only write to figure out if capslock is on, or pressing it by accident will only become noticeable if you're directly looking at whatever you're writing. So I propose making g-s-d show an OSD whenever capslock is pressed on a keyboard that has no leds to indicate so. regardless of how transient OSDs are, it will be something more noticeable than currently. I'm attaching a patch that figures that out with udev and XRawEvents, worth noting that the icons are fictional at the moment, would be great to get symbolic icons for capslock enabled/disabled
Created attachment 266572 [details] [review] media-keys: Show OSD to notify about CapsLock key on keyboards w/o leds The media keys plugin now checks for keyboards' capabilities/leds in sysfs, so if no caps lock led is available on the keyboard the user is writing to, a notification OSD is shown whenever the key is pressed so there is minimal feedback.
Compare bug 647711 which adds something similar to gnome-shell directly, for a11y status
Ah interesting, it certainly shares a few aspects, this request is a bit disconnected from sticky keys as a a11y feature though, but having this info both "permanent" and non-intrusive would be great IMO
Review of attachment 266572 [details] [review]: I like the functionality, but I don't want to be adding XI2 specific implementations to media-keys at this point. Mutter should be telling us about caps-lock status coming and going, and on which device the key press was instead. ::: plugins/media-keys/gsd-media-keys-manager.c @@ +153,3 @@ + +VirtualLedInfo virtual_led_keys[] = { + { GDK_KEY_Caps_Lock, 1 << LED_CAPSL, GDK_LOCK_MASK, This would need documenting, URL or header would be fine. @@ +2757,3 @@ + g_free (devnode); + + flags = g_udev_device_get_sysfs_attr_as_int (dev, "device/capabilities/led"); I'd rather this was exported as a property of the device in udev, but I can see that it could be seen as duplicating this value. ::: plugins/wacom/gsd-wacom-manager.c @@ +862,3 @@ type = gsd_wacom_device_get_device_type (device); + g_print ("SETWACOMSETTINGS %d\n", type); That probably shouldn't be there.
After discussing this with Carlos, we came to the conclusion that this functionality should be in gnome-shell directly, as it will filter all the keyboard events. I would however move the LED capabilities to a udev property, so we don't need to do all this processing in gnome-shell.
Posted a udev patch at: https://bugs.freedesktop.org/show_bug.cgi?id=86257 It doesn't seem to work that well though, with both my LED-less keyboards saying they have capslock and numlock :/
Carlos, if you want to look into this again, systemd has the metadata to allow doing this. I think it should be implemented directly in mutter/gnome-shell.
For the archives, systemd RFE: https://github.com/systemd/systemd/issues/5559 Commit is https://github.com/systemd/systemd/commit/b698b5cf8577d9538a6c87fbb582d34f97b3047b
Hi! Any chance this feature can be added/reviewed/approved/merged before GNOME 3.28 release? ;-) Just wondering.
(In reply to Matteo F. Vescovi from comment #9) > Hi! > Any chance this feature can be added/reviewed/approved/merged before GNOME > 3.28 release? ;-) Just wondering. Absolutely none. Feature freeze was yesterday, and nobody worked on the systemd side of the problem.
See comment #8, the systemd 'infrastructure' has been merged in Mar 2017. No-one has added keyboards to it beyond the K750 but given nothing actually uses that property we have a bit of a chicken and egg problem. But the ball is definitely in gnome's court now if we want to continue with this approach.
(In reply to Peter Hutterer from comment #11) > See comment #8, the systemd 'infrastructure' has been merged in Mar 2017. Right, I forgot I did that. > No-one has added keyboards to it beyond the K750 but given nothing actually > uses that property we have a bit of a chicken and egg problem. But the ball > is definitely in gnome's court now if we want to continue with this approach. Sure, but Matteo could add his keyboard there already...
(In reply to Bastien Nocera from comment #12) > Sure, but Matteo could add his keyboard there already... Aaaaaand done! ;-) https://github.com/systemd/systemd/pull/8433 https://github.com/systemd/systemd/pull/8490 https://github.com/systemd/systemd/pull/8492 There are already 5 ThinkPads lacking CapsLock LED that would benefit from the implementation of the OSD in GNOME, now. Hope this could help.
Hey! Almost 4 months have passed since last update and no news on this. Given a bunch of hardware definitions has been added to systemd database, now stuff should work ... or hope so! Let me know if I can help on this with testing. I'd really like to see something implemented. Thanks in advance. mfv
(In reply to Matteo F. Vescovi from comment #14) > Almost 4 months have passed since last update and no news on this. Nobody's worked on the gnome-shell side. As much as we'd all like to have this feature, there are also a finite number of hours in the day, and they're not enough.
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 ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.