Bug 7282 - AltGr doesn't work with FreeRDP
Summary: AltGr doesn't work with FreeRDP
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VNC (show other bugs)
Version: 1.3.1
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.12.0
Assignee: Pierre Ossman
URL:
Keywords: prosaic, upstream
Depends on: 7373
Blocks: 3523 7326
  Show dependency treegraph
 
Reported: 2018-11-23 14:54 CET by Pierre Ossman
Modified: 2020-01-27 09:59 CET (History)
1 user (show)

See Also:
Acceptance Criteria:


Attachments

Description Pierre Ossman cendio 2018-11-23 14:54:59 CET
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.
Comment 2 Pierre Ossman cendio 2018-11-23 15:02:53 CET
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.
Comment 3 Pierre Ossman cendio 2018-11-23 15:03:31 CET
It should be possible to work around this by removing the mapping for key 92 using this command:

  xmodmap -e "keycode 92 ="
Comment 4 Pierre Ossman cendio 2018-11-30 15:49:34 CET
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.
Comment 5 Pierre Ossman cendio 2020-01-24 14:27:17 CET
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.
Comment 6 Pierre Ossman cendio 2020-01-27 09:59:31 CET
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.

Note You need to log in before you can comment on or make changes to this bug.