xpra icon
Bug tracker and wiki

Opened 4 years ago

Closed 4 years ago

#412 closed defect (fixed)

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

Reported by: Smo Owned by: Antoine Martin
Priority: major Milestone: 0.10
Component: client Version: trunk
Keywords: win32 Cc:

Description

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

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

Attachments (2)

xpra_r4162_keyboard_test3.txt (1.7 MB) - added by alas 4 years ago.
xpra r4162 debug all test of keyboard strokes- shift and control issues
xpra_r4162_keyboard_test6.txt (22.0 KB) - added by alas 4 years ago.
xpra r4162 logs with XPRA_KEYBOARD_DEBUG=1

Download all attachments as: .zip

Change History (11)

comment:1 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to Smo

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.

comment:2 Changed 4 years ago by 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.

comment:3 Changed 4 years ago by 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.

comment:4 Changed 4 years ago by 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.

Last edited 4 years ago by alas (previous) (diff)

Changed 4 years ago by alas

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

Changed 4 years ago by alas

xpra r4162 logs with XPRA_KEYBOARD_DEBUG=1

comment:5 Changed 4 years ago by Antoine Martin

Keywords: win32 added
Milestone: 0.110.10
Owner: changed from Smo to Antoine Martin
Status: newassigned

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

comment:6 Changed 4 years ago by 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..)

comment:7 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: assignednew

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)

comment:8 Changed 4 years ago by alas

Owner: changed from alas to Antoine Martin

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

comment:9 Changed 4 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.