xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.


Changes between Initial Version and Version 4 of Ticket #1665


Ignore:
Timestamp:
12/05/17 18:21:23 (3 years ago)
Author:
Antoine Martin
Comment:

r17569 fixes the issue when overriding keyboard options on non-X11 clients: the options are sent separately, so the server no longer switches to "native" mode when it shouldn't.


The other issue turns out to be much more tricky: the reason why this sort of works is because for non-X11 clients we use a flat keymap, without using level or group. We map the keys we get from the client using the formulae:

index = group*2+level

This works reasonably well in most cases - that is for keyboards without too many levels and groups. But with the german layout, the default X11 keymap we get with setxkbmap de looks like this (using our keymap tool to dump it):

keyval          name                        keycode group   level
51              3                           12      0       0
167             section                     12      0       1
179             threesuperior               12      0       2
163             sterling                    12      0       3

All very straightforward and I believe that this matches the standard layout: standard? german keyboard layout

But the one we get from MS Windows using the same API, looks like this (ouch):

keyval          name                        keycode group   level
51              3                           51      0       0
163             sterling                    51      0       1
51              3                           51      1       0
167             section                     51      1       1
179             threesuperior               51      1       2
34              quotedbl                    51      2       0
51              3                           51      2       1
35              numbersign                  51      2       2

That's 3 groups, with up to 3 levels in groups 1 and 2. No idea how users access the extra groups and levels. And we end up mapping it like this, which isn't quite right:

51              3                           12      0       0
163             sterling                    12      0       1
179             threesuperior               12      0       2
51              3                           12      0       3

And I don't see a way to generate the correct index values from the MS Windows keymap.

This is where it gets more complicated. Here's what we get when we press the keys client side on win32 (ignoring the workarounds we need for properly detecting AltGr..):

  • "3"
    parse_key_event(<gtk.gdk.Event at 000000003129e9e0: GDK_KEY_PRESS keyval=3>, True)=<GTKKeyEvent object, contents: \
        {'modifiers': [], 'group': 1, 'string': '3', 'keyname': '3', 'pressed': True, 'keyval': 51, 'keycode': 51}>
    
  • Shift + "3"
    parse_key_event(<gtk.gdk.Event at 000000003129e990: GDK_KEY_PRESS keyval=section>, True)=<GTKKeyEvent object, contents: \
        {'modifiers': ['shift'], 'group': 1, 'string': '\xa7', 'keyname': 'section', 'pressed': True, 'keyval': 167, 'keycode': 51}>
    
  • AltGr + "3":
    parse_key_event(<gtk.gdk.Event at 000000003129ed28: GDK_KEY_PRESS keyval=threesuperior>, True)=<GTKKeyEvent object, contents: \
        {'modifiers': ['mod5'], 'group': 1, 'string': '\xb3', 'keyname': 'threesuperior', 'pressed': True, 'keyval': 179, 'keycode': 51}>
    
  • AltGt + Shift + "3"
    parse_key_event(<gtk.gdk.Event at 000000003129ec38: GDK_KEY_PRESS keyval=threesuperior>, True)=<GTKKeyEvent object, contents: \
        {'modifiers': ['shift', 'mod5'], 'group': 1, 'string': '\xb3', 'keyname': 'threesuperior', 'pressed': True, 'keyval': 179, 'keycode': 51}>
    

This last one differs from the X11 keymap, which gives "sterling" instead.

I believe that what we should be doing is to leave the server-side "de" keymap as it is after we call setxkbmap de (I am oversimplifying here), then:

  • add extra modifiers (Alt_R can go MIA, etc)
  • add missing keysyms to unbound keycodes
  • generate the translation table so that keycodes map to the server keycode (and ignore the keyname? ignore the string?) - that way, as long as the modifiers are set correctly, we should get the right key
  • continue to ignore the group attribute, level should be managed by Shift / CapsLock

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #1665

    • Property Status changed from new to assigned
    • Property Priority changed from major to critical
  • Ticket #1665 – Description

    initial v4  
    55
    66Example:
    7 The pipe symbol "|" is "AltGR"+"<" on a german keyboard.
    8 In an xpra session you only get "<".
    9 Same for "@" ("AltGr"+"q") and others.
     7The pipe symbol {{{|}}} is {{{AltGR}}} + {{{<}}} on a german keyboard.
     8In an xpra session you only get {{{<}}}.
     9Same for {{{@}}} ({{{AltGr}}} + {{{q}}}) and others.
    1010
    1111Server:
     
    1616  * Win 7 x86_64
    1717  * xpra v2.1.2-r16904
    18   * Xpra_cmd.exe start ssh:%CENTOS7-SERVER% --start-child="xterm -ls" --debug=keyboard
     18  * {{{Xpra_cmd.exe start ssh:%CENTOS7-SERVER% --start-child="xterm -ls" --debug=keyboard}}}
    1919
    2020