#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)
Change History (12)
comment:1 Changed 8 years ago by
Owner: | changed from Antoine Martin to Smo |
---|
comment:2 Changed 8 years ago by
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 8 years ago by
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 8 years ago by
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.
Changed 8 years ago by
Attachment: | xpra_r4162_keyboard_test3.txt added |
---|
xpra r4162 debug all test of keyboard strokes- shift and control issues
Changed 8 years ago by
Attachment: | xpra_r4162_keyboard_test6.txt added |
---|
xpra r4162 logs with XPRA_KEYBOARD_DEBUG=1
comment:5 Changed 8 years ago by
Keywords: | win32 added |
---|---|
Milestone: | 0.11 → 0.10 |
Owner: | changed from Smo to Antoine Martin |
Status: | new → assigned |
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 8 years ago by
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 8 years ago by
Owner: | changed from Antoine Martin to alas |
---|---|
Status: | assigned → new |
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 8 years ago by
Owner: | changed from alas to Antoine Martin |
---|
I can't find any sign of any regressions. Back to you Antoine.
comment:9 Changed 8 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
applied to v0.10.x in r4312 and is included in 0.10.4
comment:10 Changed 3 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/412
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
.