I found this issue when running xpra in a Docker container with Ubuntu 17.10 artful and using the HTML5 client. This bug is present in both version of xpra and only in HTML5 client.
If I try to type the "less than" character (<) pressing "shift+," when using the HTML5 client, I get the "greater than" character (>). This happens on both stable and beta HTML5 clients, but not with the desktop client. My keyboard has the US layout and has 104 keys. In the logs I see that the "us" layout is chosen by xpra and that the ctrl key press is recognized by xpra. Other keys with issues are the 4 in the top right corner of the keyboard (top right corner of the numpad): /, *, - and +. These four are mapped to the similar keys in the main part of the keyboard, thus when I press "*" I get "8" and I have to press "shift+*" to get the "*".
I wrote a couple of Dockerfiles to test the latest stable (xpra X11 version 2.3.2-r19729 64-bit as of this writing) and the latest beta version (xpra X11 version 2.4-r19803 64-bit as of this writing) and I found some bugs when comparing the HTML5 client to the Xpra desktop client I use on my Arch Linux running PC.
The Docker images are based on Ubuntu 17.10 artful and I attach the Dockerfiles so that my experiments can be reproduced.
To build the images, I run the following commands:
sudo docker build -t xpra -f path/to/xpra/Dockerfile path/to/xpra/ sudo docker build -t xpra:beta -f path/to/xpra/Dockerfile-beta path/to/xpra/
To run the containers, I enter the following:
sudo docker run --interactive --tty --rm -p 8080:8080 xpra sudo docker run --interactive --tty --rm -p 8080:8080 xpra:beta
Can you please attach the server log and an xpra info
snapshot of when the html5 client is connected? (more general keyboard bug reporting guidelines here: wiki/Keyboard)
screenshot of xev output when trying to type greater and lesser than
I attached some dumps. I am not able to delete the file "xpra-info.txt" that was dumped in a previous run, while all other file are from the same run. Here are the two smaller dumps:
$ setxkbmap -print xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+us+inet(evdev)" }; xkb_geometry { include "pc(pc105)" }; };
$ setxkbmap -query rules: evdev model: pc105 layout: us
See also #1898
I can reproduce. The problem does not occur when selecting a UK layout in the advanced options.
Here's the keyboard debug log for Shift
+ ,
:
client keyboard processKeyEvent( true , [object KeyboardEvent] ) key= ShiftLeft keycode= 16 client keyboard passing clipboard modifier key event to browser: Shift_L client keyboard key-action,1,Shift_L,true,shift,mod2,16,Shift,16,0 set_keyboard_layout_group(0) config=KeyboardConfig(us / None / None), current keyboard group=0 get_keycode(16, Shift_L, ('shift', 'mod2')) keyname+keycode lookup: 50 process_key_action(['key-action', 1, 'Shift_L', 1, ['shift', 'mod2'], 16, 'Shift', 16, 0]) server keycode=50 filtered_modifiers_set(['mod2'])=set(['mod2']) modifier 'shift' ignored (in ignored keynames=set(['Shift_L', 'Shift_R'])) filtered_modifiers_set(('shift', 'mod2'))=set(['mod2']) handle_key(1,1,Shift_L,16,50,('shift', 'mod2')) keyboard_sync=True handle keycode pressing 50: key 'Shift_L' fake_key(50, True) client keyboard processKeyEvent( true , [object KeyboardEvent] ) key= Comma keycode= 188 set_keyboard_layout_group(0) config=KeyboardConfig(us / None / None), current keyboard group=0 client keyboard key-action,1,less,true,shift,mod2,188,<,188,0 get_keycode(188, less, ('shift', 'mod2')) keyname lookup: 94 process_key_action(['key-action', 1, 'less', 1, ['shift', 'mod2'], 188, '<', 188, 0]) server keycode=94 filtered_modifiers_set(['mod2', 'shift'])=set(['shift', 'mod2']) filtered_modifiers_set(('shift', 'mod2'))=set(['shift', 'mod2']) handle_key(1,1,less,188,94,('shift', 'mod2')) keyboard_sync=True is_modifier(94) not found handle keycode pressing 94: key 'less' fake_key(94, True) client keyboard processKeyEvent( false , [object KeyboardEvent] ) key= Comma keycode= 188 set_keyboard_layout_group(0) config=KeyboardConfig(us / None / None), current keyboard group=0 client keyboard key-action,1,less,false,shift,mod2,188,<,188,0 get_keycode(188, less, ('shift', 'mod2')) keyname lookup: 94 process_key_action(['key-action', 1, 'less', 0, ['shift', 'mod2'], 188, '<', 188, 0]) server keycode=94 filtered_modifiers_set(['mod2', 'shift'])=set(['shift', 'mod2']) filtered_modifiers_set(('shift', 'mod2'))=set(['shift', 'mod2']) handle_key(1,0,less,188,94,('shift', 'mod2')) keyboard_sync=True is_modifier(94) not found handle keycode unpressing 94: key 'less' fake_key(94, False) client keyboard processKeyEvent( false , [object KeyboardEvent] ) key= ShiftLeft keycode= 16 client keyboard passing clipboard modifier key event to browser: Shift_L client keyboard key-action,1,Shift_L,false,mod2,16,shift,16,0 set_keyboard_layout_group(0) config=KeyboardConfig(us / None / None), current keyboard group=0 get_keycode(16, Shift_L, ('mod2',)) keyname+keycode lookup: 50 process_key_action(['key-action', 1, 'Shift_L', 0, ['mod2'], 16, 'shift', 16, 0]) server keycode=50 modifier 'shift' ignored (in ignored keynames=set(['Shift_L', 'Shift_R'])) filtered_modifiers_set(['mod2', 'shift'])=set(['mod2']) filtered_modifiers_set(('mod2',))=set(['mod2']) handle_key(1,0,Shift_L,16,50,('mod2',)) keyboard_sync=True handle keycode unpressing 50: key 'Shift_L' fake_key(50, False)
From the top:
Shift_L
is correct:
$ DISPLAY=:2 xmodmap -pm | grep Shift_L shift Shift_L (0x32), Shift_R (0x3e) $ DISPLAY=:2 xmodmap -pke | grep Shift_L keycode 50 = Shift_L NoSymbol Shift_L
$ DISPLAY=:2 xmodmap -pm | grep mod2 mod2 Num_Lock (0x4d)
<
looks correct:
['key-action', 1, 'less', 1, ['shift', 'mod2'], 188, '<', 188, 0] server keycode=94
But the key that we find in the keymap is not the right one:
$ DISPLAY=:2 xmodmap -pke | grep less keycode 59 = comma less comma less keycode 94 = less greater less greater bar brokenbar bar
We should be using 59 and not 94. That's because we match the keycode by keysym, not taking into account the modifier state.
Let's fix this then I'll take a look at the other keys.
Here's the key mapping phase:
XPRA_DEBUG_KEYSYMS=less xpra start ... setting keyboard layout to 'us' set_keycode_translation: find_keycode(60, 'less', 0) x11 keycodes=(59, 94) x11 keycode 59: ['comma', 'less', 'comma', 'less'] x11 keycode 94: ['less', 'greater', 'less', 'greater', 'bar', 'brokenbar', 'bar'] set_keycode_translation: find_keycode(60, 'less', 0)=94 (exact index match)
Patch to follow.
add extra keysyms so we can match them precisely, including the shift level
Patch merged in r20420 with one important change: the order of the (keysym, level)
pair is reversed so that we never mistakenly match or override the (keycode, keysym)
pair. (int, str) vs (str, int)
This creates some "interesting" data structure mangling in places that only expect the latter (ie: older clients - but no actual regression bugs so far).
r20422 allows us to use this new modifier mapping map format, which should help AlrGr
work in more cases, r20423 handles it better server side.
Related: r20421 tries to workaround a GTK3 bug which looks awfully similar to Crash when accessing the "string" attribute of GdkEventKey on 64bit Windows which we recorded in #1818.
Ubuntu beta packages are available: https://xpra.org/beta. In theory, all of these fixes could be backported - not sure I am brave enough..
@Matteo Ipri: does that work for you?
Important fixes for non-US keyboard layout handling.
Tested this with Firefox (61) and Chrome (69) in Fedora 28 and Windows 8.1 with a trunk r20530 Fedora 28 server, and everything appears to be right about what I expect.
I don't have access to any non-US keyboards, but I do have multiple layouts installed and the keys show up right about where they should be.
Closing.
Keyboard support much improved in #2574.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1902