https://bugs.kde.org/show_bug.cgi?id=417860
BXLSTNRD <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from BXLSTNRD <[email protected]> --- I found a possibly related issue while investigating KDE Connect remote input on Wayland. My reproduction is not the same as this Caps Lock case, so I do not want to claim that Bug 417860 and the issue I investigated have the same root cause. However, the investigation exposed a closely related weakness in how KDE Connect handles XKB modifier state in the Wayland/libei input path. In KDE Connect 26.08.1, the keysym-to-keycode conversion can find the requested character on the correct XKB level, but only the physical keycode is retained. The required modifier information is then lost before injection. A local proof-of-concept which preserved and synthesized the required Shift / Level3 / Level5 modifiers fixed the tested cases. One of the remaining limitations I explicitly identified is synchronization between KDE Connect's stored XKB state and the actual physical lock/modifier state of the seat. That seems potentially relevant to the Caps Lock behaviour described in this bug. Full analysis and proof-of-concept: https://bugs.kde.org/show_bug.cgi?id=429400#c12 I am only cross-referencing this because of the modifier-state overlap; I have not reproduced this specific Caps Lock scenario against the patched code. -- You are receiving this mail because: You are watching all bug changes.
