I have looked through the steps described in the keyboard wiki and learned the following.
When I run the client and server with the -d keyboard
flag, both client and server report the correct keypresses for all three keys ('|', '<', and '>') in the client and server logs.
Example :
send_key_action(5, <GTKKeyEvent object, contents: {'modifiers': ['mod2', 'shift'], 'group': 0, 'string': '|', 'keyname': 'bar', 'pressed': True, 'keyval': 124, 'keycode': 51}>)
When I run keymap.py on both a working Ubuntu server and this broken CentOS server, I get the following behavior which seems wrong to me:
keyval name keycode group level 60 less 94 0 0 62 greater 94 0 1 124 bar 94 0 2 166 brokenbar 94 0 3
I am mostly ignorant of X keyboard conventions, but all three of the keys I'm having a problem with are mapped to keycode 94, even though they are different keyvals. I don't know what the "level" column means, but maybe that's how it works correctly on Ubuntu?
When I run gtk_view_keyboard.py or xev on the client X session, all three keypresses show up as ">" (greater) key.
gtk_view_keyboard.py (it doesn't describe the columns)
down greater > 62 94 0 0 ['2', 'S']
xev
KeyPress event, serial 36, synthetic NO, window 0x600001, root 0x25d, subw 0x0, time 2033540430, (-1140,517), root:(2059,535), state 0x11, keycode 94 (keysym 0x3e, greater), same_screen YES, XKeysymToKeycode returns keycode: 60 XLookupString gives 1 bytes: (3e) ">" XmbLookupString gives 1 bytes: (3e) ">" XFilterEvent returns: False
Using the same client (v2.2.1-r17715) on two different servers, Ubuntu (xpra v2.2.1-r17715) and CentOS (xpra v2.2-r17607) I get a working session between client and Ubuntu, and this keymap problem between client and CentOS. As far as I can tell, all the keyboard debug information is the same between the Ubuntu server and the CentOS server.
This client and both servers have been working well together for a long time. I do not know for sure what changed between when it was working and now, but most likely only the client side changed.
As far as I can tell the CentOS repository is serving up r17607 as the newest version, so I cannot easily update that side.
I can provide whatever other information is needed.
This sounds like the problems that were fixed in 2.2.1 by this change: r17667.
I'm not sure why the centos7 2.2.1 packages had gone MIA, but they're there now, so you should be able to get going again with just a yum update
.
Sorry about that.
Update fixed the problem, thanks!
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1737