https://bugs.kde.org/show_bug.cgi?id=402019
BXLSTNRD <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #10 from BXLSTNRD <[email protected]> --- I am cross-referencing a possibly related KDE Connect keyboard-input investigation, but I want to be careful not to imply that it explains this bug. The issue I investigated is in the opposite direction: Android remote input → Plasma Wayland, while this report primarily concerns desktop → Android input and accented/dead-key characters. In KDE Connect 26.08.1 I traced a desktop-side Wayland/libei issue where keysym-to-keycode conversion can find a requested character on the correct XKB level, but then retains only the physical keycode and loses the modifier required to select that level. A local proof-of-concept which preserved and synthesized Shift / ISO_Level3_Shift / ISO_Level5_Shift fixed the modifier-based cases I tested. Full analysis and proof-of-concept: https://bugs.kde.org/show_bug.cgi?id=429400#c12 I do not currently have evidence that this modifier-loss explains the dead-key / Compose-sequence behaviour reported in Bug 402019. In fact, the distinction described in comment 5/6 here between multi-key dead-key sequences and modifier-based input suggests there may be a separate issue involved. I am adding this only because both investigations concern KDE Connect translating keyboard semantics across devices/layouts, and the findings may be useful when reviewing the broader input architecture. My current proof-of-concept does not attempt to handle dead keys, Compose sequences or arbitrary Unicode text input. -- You are receiving this mail because: You are watching all bug changes.
