If an XWayland client sets the state of caps lock as opposed to the state of the caps lock key changing in response to a user's keypress, the caps lock LED goes out of sync (e.g. if caps lock is turned off by the client, the LED will stay on). It should be noted that the keyboard (Nighthawk X7) I'm able to reproduce this on exposes multiple input devices, and unfortunately the input device that controls the actual caps lock LED is different from the input device that sends normal keypresses. If you have trouble reproducing this bug normally then this is probably the reason. The version of XWayland I'm using is 1.18
Ugh, this is really nasty. Do you have a sample client which does this? We'd need to add new XWayland-specific protocol, to allow it to drive the state itself.
(In reply to Daniel Stone from comment #1) > Ugh, this is really nasty. Do you have a sample client which does this? > > We'd need to add new XWayland-specific protocol, to allow it to drive the > state itself. Yes, gvim with https://github.com/suxpert/vimcaps installed. Go into insert mode, turn on caps lock, and leave insert mode. gvim will try to turn off caps lock but the LED won't update properly and it will stay on outside of the application.
Good god, that is ... creative. Sigh, yep, I guess in the compositor <-> XWayland protocol, we'd need support for forcibly changing the xkbcommon modifier state.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/695.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.