We've gotten a report that AltGr isn't working correctly when running FreeRDP inside a ThinLinc session. We haven't verified why this happens, but the theory is that it is because we end up sending a different key code for AltGr compared to a local session. In ThinLinc you get: > KeyPress event, serial 37, synthetic NO, window 0x4800001, > root 0xaa, subw 0x0, time 1307059380, (100,275), root:(550,712), > state 0x0, keycode 92 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, > XLookupString gives 0 bytes: > XmbLookupString gives 0 bytes: > XFilterEvent returns: False But locally you get: > KeyPress event, serial 38, synthetic NO, window 0x4800001, > root 0xaa, subw 0x0, time 1307349728, (475,-52), root:(925,385), > state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, > XKeysymToKeycode returns keycode: 92 > XLookupString gives 0 bytes: > XmbLookupString gives 0 bytes: > XFilterEvent returns: False FreeRDP is most likely trying to map physical keys (like bug 4560) rather than symbols, so it really needs to get the "correct" key code.
This is a bit of a perfect storm that causes this. The reason we send 92 instead of 108 is that all standard layouts that have AltGr will have it configured on both of those keys. And Xvnc will use the first key that matches, so it will find 92 before 108 and use that. The reason why there are two allocations is that AltGr is not in every layout, but it was convenient for the X11 developers to always have every modifier present somewhere in every layout. So they noticed that there was a few key codes that the keyboard driver would never use. Those codes were then given one modifier each and present in every possible layout. For a local desktop this didn't cause any issue since the keyboard driver would never send these "fake" keys. Given this knowledge, perhaps we can modify our lookup to prefer "normal" keys over these special ones that aren't expected to be used.
It should be possible to work around this by removing the mapping for key 92 using this command: xmodmap -e "keycode 92 ="
I made an attempt at implementing the "fallback" theory upstream: https://github.com/TigerVNC/tigervnc/pull/772/commits/0255e1b004fe6518c650e9d12b8862c2b2dad30b Seems to solve the issue for FreeRDP, so we'll get this resolved as part of the next vendor drop.
FreeRDP already works anyway because they added compatibility for these keys: https://github.com/FreeRDP/FreeRDP/pull/5142 But for older versions and other applications it's probably best to verify our new improved behaviour in Xvnc anyway.
I can confirm that previous versions send keycode 92 for AltGr, but the current build sends 108 instead, just like on the local system. Not bothering with release notes as it already works in FreeRDP because of their workaround.
