Win32 Client - Shift and CTRL buttons fail to stay pressed down

[Smo]

When holding shift or ctrl only the first keystroke is registered.

Also with --no-keyboard-sync shift and ctrl don't function at all.

[Antoine Martin]

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.

[alas]

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.

[Antoine Martin]

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.

[alas]

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.

[alas]

xpra r4162 debug all test of keyboard strokes- shift and control issues

[alas]

xpra r4162 logs with XPRA_KEYBOARD_DEBUG=1

[Antoine Martin]

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..

[Antoine Martin]

Looks like two bugs in one!

• 'Shift' timesout on all platforms because we don't get repeat key events client side - but on other platforms, we do re-set it later which hides this first bug
• then there's the problem of win32 client failing to re-press it when processing the next keypress (and I think the answer to this one is a win32 workaround already..)

[Antoine Martin]

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)

[alas]

I can't find any sign of any regressions. Back to you Antoine.

[Antoine Martin]

applied to v0.10.x in r4312 and is included in 0.10.4