This is probably a minor problem peculiar to this particular program, but perhaps the underlying bug is implicated in other problems, too.
The program in question is an extremely fast pdf reader called mupdf http://mupdf.com/ I downloaded the program from the website and compile it. I use it to quickly peek a pdf document. In version 0.15, I can use the usual keyboard shortcuts to resize the window (e.g. + or -) reload the page (r) etc. However, none of these single key shortcuts work in 0.16. I don't see any error in the log on the server or client side.
My systems are 64 bit 0.16.1-1 beta, released on Dec. 30 2015, on Ubuntu 14.04, both installed from the beta .deb files from the xpra website (thank you for keeping us trusty people afloat with these beta packages!) I am using rgb raw images with lz4 compression.
As I said, I have only observed the problem with mupdf, but not many other programs use single key shortcuts so this may affect other things as well.
Also, it appears 0.16 branch has much better-behaved audio and the audio-video sync is much better, just as promised! Thank you for these improvement!
As I said, I have only observed the problem with mupdf, but not many other programs use single key shortcuts so this may affect other things as well.
Thanks for reporting this!
Confirmed. With 0.15.x server (client version makes no difference):
send_key_action(2, <GTKKeyEvent object, contents: \
{'modifiers': ['mod2', 'shift'], 'group': 0, 'string': '+', \
'keyname': 'plus', 'pressed': True, 'keyval': 43, 'keycode': 21}>)
send_key_action(2, <GTKKeyEvent object, contents: \
{'modifiers': ['mod2', 'shift'], 'group': 0, 'string': '+', \
'keyname': 'plus', 'pressed': False, 'keyval': 43, 'keycode': 21}>)
get_keycode(21, plus, ('mod2', 'shift')) native keymap, using unmodified keycode: 21
handle_key(2,True,plus,43,21,('mod2', 'shift')) keyboard_sync=True
is_modifier(21) not found
handle keycode pressing 21: key plus
fake_key(21, True)
scheduling key repeat timer with delay 500 for plus / 21
get_keycode(21, plus, ('mod2', 'shift')) native keymap, using unmodified keycode: 21
handle_key(2,False,plus,43,21,('mod2', 'shift')) keyboard_sync=True
is_modifier(21) not found
handle keycode unpressing 21: key plus
fake_key(21, False)
With 0.16:
get_keycode(21, plus, ('mod2', 'shift')) native keymap, using unmodified keycode: 21
filtered_modifiers_set(['mod2', 'shift'])=shift, mod2
filtered_modifiers_set(('mod2', 'shift'))=shift, mod2
handle_key(2,True,plus,43,21,('mod2', 'shift')) keyboard_sync=True
is_modifier(21) not found
handle keycode pressing 21: key plus
fake_key(21, True)
scheduling key repeat timer with delay 500 for plus / 21
get_keycode(21, plus, ('mod2', 'shift')) native keymap, using unmodified keycode: 21
filtered_modifiers_set(['mod2', 'shift'])=shift, mod2
filtered_modifiers_set(('mod2', 'shift'))=shift, mod2
handle_key(2,False,plus,43,21,('mod2', 'shift')) keyboard_sync=True
is_modifier(21) not found
handle keycode unpressing 21: key plus
fake_key(21, False)
Bar some logging differences, the steps look identical.
xev shows identical events:
KeyPress event, serial 37, synthetic NO, window 0xc00001,
root 0x25d, subw 0x0, time 11193155, (88,90), root:(2083,194),
state 0x11, keycode 21 (keysym 0x2b, plus), same_screen YES,
XLookupString gives 1 bytes: (2b) "+"
XmbLookupString gives 1 bytes: (2b) "+"
XFilterEvent returns: False
KeyRelease event, serial 37, synthetic NO, window 0xc00001,
root 0x25d, subw 0x0, time 11193227, (88,90), root:(2083,194),
state 0x11, keycode 21 (keysym 0x2b, plus), same_screen YES,
XLookupString gives 1 bytes: (2b) "+"
XFilterEvent returns: False
So I suspect that the problem is not in the keyboard layer but maybe focus related instead. One way to identify the problem would be to bisect it...
r9839 is the problem, and it is focus related.
Should be fixed in r11742, will backport.
Backport to v0.16.x in r11748, there are beta builds for trusty with this fix.
If this works for you, please close this ticket. Many thanks for reporting this regression!
This defect is fixed in the latest beta. Thank you for that!
However, mupdf is still not behaving properly as before or as under forwarded X11 window. I've filed a new ticket #1097.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1092