https://bugs.kde.org/show_bug.cgi?id=519973
boylair <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #3 from boylair <[email protected]> --- Can confirm this also happens on a Hungarian layout, so it's not AZERTY-specific, and it doesn't require caps lock to trigger. My case is plain mixed-case typing through NotifyKeyboardKeysym on the RemoteDesktop portal (not KDE Connect, a different client), e.g. typing "Hello World" character by character with no caps lock involved at all. Setup: KWin 6.7.3, xdg-desktop-portal-kde 6.7.3, Arch Linux, Hungarian layout. After the first uppercase letter, every following character comes out uppercase, including ones sent as lowercase keysyms, so the modifier state clearly latches at the compositor level rather than being applied per keystroke. I checked with dbus-monitor on the RemoteDesktop portal interface and every NotifyKeyboardKeysym call is correctly paired, press followed by release, nothing dropped on the client side, so the keysym to keycode translation and the resulting XKB modifier state on the KWin side looks like the right place to keep looking, matching your diagnosis of the updateModifiers() broadcast rather than the client sending inconsistent events. While it was stuck, Enter also misbehaved, the focused terminal seemed to read it as Shift+Enter and didn't submit the command, consistent with a globally latched Shift modifier rather than something scoped to a single key event. Sending an isolated Shift key combination explicitly, as separate keycode press and release events through NotifyKeyboardKeycode rather than through the keysym path, did not trigger the bug and worked as expected. -- You are receiving this mail because: You are watching all bug changes.
