https://bugs.kde.org/show_bug.cgi?id=478262
BXLSTNRD <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #1 from BXLSTNRD <[email protected]> --- I found a possibly related issue while investigating KDE Connect remote input on Wayland. My tested setup is not identical to this report: I tested Android → Plasma rather than Plasma → Plasma, so I do not want to claim that this explains the different source/target layout behaviour reported here. However, the reported inability to use AltGr may overlap with a desktop-side issue I traced in KDE Connect 26.08.1. In the Wayland/libei remote-input path, the keysym-to-keycode conversion can find a character on an XKB Level3/AltGr level, but only the physical keycode is retained. The modifier required to reach that level is then lost before injection. In my tests this affected Shift characters as well as Level3 characters. A local proof-of-concept which preserved and synthesized the required Shift / ISO_Level3_Shift / ISO_Level5_Shift modifiers corrected the tested behaviour, including € on a Belgian be/oss layout. I documented the reproduction, failure point, tests and proof-of-concept here: https://bugs.kde.org/show_bug.cgi?id=429400#c12 Again, this may explain the AltGr/Level3 part of this report, but probably not the broader question of whether KDE Connect remote input should follow the source or target keyboard layout. -- You are receiving this mail because: You are watching all bug changes.
