When holding shift or ctrl only the first keystroke is registered.
Also with --no-keyboard-sync
shift and ctrl don't function at all.
This is win32 only, right?
What does the gtk keyboard tool shown when used from inside that session?
Also, please post the log with XPRA_KEYBOARD_DEBUG=1
.
Shift and Control work fine on osx and fedora, so yes, it seems to only be a win32 issue.
gtk keyboard tool output:
Client-side keyboard: down Shift_L 65505 16 0 0 ['S'] down Shift_L 65505 16 0 0 ['S'] {etc.} down S S 83 83 0 0 ['S'] {etc.} up Shift_L 65505 16 0 0 ['S'] down/up s s 115 83 0 0 [] {etc.} Server-side: down/up s s 115 39 0 0 ['2'] down/up s s 115 39 0 0 ['2'] down Shift_L 65505 50 1 0 ['2'] down/up S S 83 39 0 0 ['2', 'S'] {with shift_L still depressed} up Shift_L 65505 50 1 0 ['2', 'S'] down/up s s 115 39 0 0 ['2'] down/up s s 115 39 0 0 ['2'] {re-pressing shift_L} down Shift_L 65505 50 1 0 ['2'] down/up S S 83 39 0 0 ['2', 'S'] {again while shift_L is still depressed} up Shift_L 65505 50 1 0 ['2', 'S'] down/up s s 115 39 0 0 ['2']
The log with XPRA_KEYBOARD_DEBUG=1 showed only 34 MB of Nvidia graphics warnings and one instance of a speaker re-start (audio recovered promptly).
If you'd like -d all logs I'll leave it to Smo to generate some without all those warnings, or I could use --opengl=off to generate some if you're not worried about different behavior.
The log with XPRA_KEYBOARD_DEBUG=1 showed only 34 MB of Nvidia graphics warnings and one instance of a speaker re-start (audio recovered promptly).
Then disable GL and disable speaker.
Ok, I'm attaching logs with win32 r4162, --opengl=off
and XPRA_KEYBOARD_DEBUG=1
. Looks like I hadn't set the output right with the last attempt.
The server-side keyboard tool behaves the same as above, though a Caps_Lock use displays the following, for comparison:
down Caps_Lock 65509 66 1 0 ['2'] up Caps_Lock 65509 66 0 0 ['2', 'L'] down/up H H 72 43 0 0 ['2', 'L'] down/up H H 72 43 0 0 ['2', 'L'] down/up Caps_Lock 65509 66 1 0 ['2', 'L']
Meanwhile, for an idea of the behavior inside the xpra session (with a google-chrome browser in this particular case):
{Using shift key in email compose buffer within xpra session} Ggghhjjn {using caps lock} FHNDFHURFN {using shift} AHAHahahahhahha {using shift} DJDJDJjdjdjjdjdjjnndk {using shift} Djdjdj
The precise number of keys that are "captured" by the proper shift behavior seems to depend on how quickly one inputs the keys.
Control key behaves similarly. Using control-t to open new tabs in one case opened 3 new tabs before spitting ttttttttttttttt
out on the address bar, in another case only one new tab was opened before spitting out tttttttttttt
.
In case they might be of use, I also ran with -d all
and am attaching that log.
Let me know if there's some other flag that can be tried for better results.
xpra r4162 debug all test of keyboard strokes- shift and control issues
xpra r4162 logs with XPRA_KEYBOARD_DEBUG=1
Confirmed on win32 only, OSX and Linux clients are not affected.
Just captured some debug logging whilst holding Shift and then holding 'S':
#Shift pressed: 2013-09-06 12:49:49,249 process_key_action([44, 1, 'Shift_L', True, ('shift', 'mod2'), 65505, '', 16, 0]) server keycode=50 2013-09-06 12:49:49,250 handle_key(1,True,Shift_L,65505,50,('shift', 'mod2')) keyboard_sync=True 2013-09-06 12:49:49,250 handle keycode pressing 50: key Shift_L 2013-09-06 12:49:49,251 scheduling key repeat timer with delay 750 for Shift_L / 50 #'S' pressed: 2013-09-06 12:49:49,624 process_key_action([44, 1, 'S', True, ('shift', 'mod2'), 83, 'S', 83, 0]) server keycode=39 2013-09-06 12:49:49,625 handle_key(1,True,S,83,39,('shift', 'mod2')) keyboard_sync=True 2013-09-06 12:49:49,626 handle keycode pressing 39: key S 2013-09-06 12:49:49,627 scheduling key repeat timer with delay 750 for S / 39 #Shift times out: 2013-09-06 12:49:50,002 key repeat timeout for Shift_L / '50' - clearing it, now=1378446590.0, scheduled at 1378446589.25 with delay=750 2013-09-06 12:49:50,003 handle_key(1,False,Shift_L,65505,50,('shift', 'mod2')) keyboard_sync=True 2013-09-06 12:49:50,003 handle keycode unpressing 50: key Shift_L 2013-09-06 12:49:50,004 cancelling key repeat timer: 656 for Shift_L / 50 #'S' repeat: 2013-09-06 12:49:50,375 process_key_action([44, 1, 'S', True, ('shift', 'mod2'), 83, 'S', 83, 0]) server keycode=39 2013-09-06 12:49:50,376 handle_key(1,True,S,83,39,('shift', 'mod2')) keyboard_sync=True 2013-09-06 12:49:50,376 handle keycode 39: key S was already pressed, ignoring 2013-09-06 12:49:50,376 cancelling key repeat timer: 661 for S / 39 2013-09-06 12:49:50,377 scheduling key repeat timer with delay 750 for S / 39 #'S' repeat: 2013-09-06 12:49:50,412 process_key_action([44, 1, 'S', True, ('shift', 'mod2'), 83, 'S', 83, 0]) server keycode=39 2013-09-06 12:49:50,413 handle_key(1,True,S,83,39,('shift', 'mod2')) keyboard_sync=True 2013-09-06 12:49:50,414 handle keycode 39: key S was already pressed, ignoring 2013-09-06 12:49:50,415 cancelling key repeat timer: 667 for S / 39 2013-09-06 12:49:50,416 scheduling key repeat timer with delay 750 for S / 39 #'S' repeat: 2013-09-06 12:49:50,447 process_key_action([44, 1, 'S', True, ('shift', 'mod2'), 83, 'S', 83, 0]) server keycode=39 2013-09-06 12:49:50,449 handle_key(1,True,S,83,39,('shift', 'mod2')) keyboard_sync=True 2013-09-06 12:49:50,449 handle keycode 39: key S was already pressed, ignoring 2013-09-06 12:49:50,450 cancelling key repeat timer: 675 for S / 39 2013-09-06 12:49:50,450 scheduling key repeat timer with delay 750 for S / 39 #etc..
Looks like two bugs in one!
Should be fixed in r4288, please test to verify that this does not cause regressions with other modifiers (capslock, numlock, etc.)
Then please re-assign to me so I can apply to v0.10.x, then I will also change the code to be more correct (the current fix makes assumptions about keynames, and this code belongs on the keyboard class not in the server class)
I can't find any sign of any regressions. Back to you Antoine.
applied to v0.10.x in r4312 and is included in 0.10.4
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/412