#2478 closed defect (fixed)
Problems sending control characters
Reported by: | Bob Babcock | Owned by: | Bob Babcock |
---|---|---|---|
Priority: | minor | Milestone: | 4.0 |
Component: | keyboard | Version: | 3.0.x |
Keywords: | control win32 | Cc: |
Description
Viewing Fedora 31 with xpra 3.0.2 from Windows 7, I see problems sending control characters. I first noticed this when viewing a remote desktop session in remmina where I could occasionally send control characters, but usually not. But they seem to be ok in the xterm used to launch remmina. I don't see this problem with 3.0.1.
Running keyboard-test I see right control up/down events, but nothing for left control. That's also true with 3.0.1.
Attachments (1)
Change History (11)
comment:1 Changed 16 months ago by
Keywords: | win32 added |
---|---|
Priority: | major → critical |
Status: | new → assigned |
comment:2 Changed 16 months ago by
Owner: | changed from Antoine Martin to Bob Babcock |
---|---|
Status: | assigned → new |
This should be fixed in r24414 - looks like it had been broken for a very long time.
(and we're still getting spurious key events when AltGr
is pressed..)
There is a beta build with this fix here: https://xpra.org/beta/windows/.
@wssddc: does that fix things for you?
comment:3 Changed 16 months ago by
comment:4 Changed 16 months ago by
Just tested remote desktop behavior. Under Windows 10, left control is recognized, but right control is not. Both work in a xterm.
r24414 won't even start under Windows 7. xpra with no arguments yields "xpra initialization error" and quits.
The installer I used was Xpra-Python3_Setup_4.0-r24414.exe
This seems to be a 32-bit version. I have no complaint about that, but I thought you were dropping 32-bit support.
comment:5 Changed 15 months ago by
Priority: | critical → minor |
---|
Changed 15 months ago by
Attachment: | keyboard-state.png added |
---|
keyboard-test showing both control-left and control-right events
comment:6 Changed 15 months ago by
This seems to be a 32-bit version. I have no complaint about that, but I thought you were dropping 32-bit support.
It won't be officially fully supported, but I will still be making builds from time to time, for now anyway.
... left control works, right control doesn't.
I've run the xpra keyboard-test
command server side and the control keys showed up as they should:
Then I enabled -d keyboard
debugging (actually, I modified my running server with: xpra control :2 debug enable keyboard
).
- control-left showed:
set_keyboard_layout_group(0) config=KeyboardConfig(gb / / None), current keyboard group=0 get_keycode(17, Control_L, ('control',))=37 (level=0) process_key_action(['key-action', 3, b'Control_L', True, (b'control',), 65507, b'', 17, 0]) server keycode=37 filtered_modifiers_set([])=set() modifier 'control' ignored (in ignored keynames={'Control_R', 'Control_L'}) filtered_modifiers_set(('control',))=set() handle_key((3, True, 'Control_L', 65507, 37, ('control',), True, True)) handle keycode pressing 37: key 'Control_L' fake_key(37, True) set_keyboard_layout_group(0) config=KeyboardConfig(gb / / None), current keyboard group=0 process_key_action(['key-action', 3, b'Control_L', False, (), 65507, b'', 17, 0]) server keycode=37 modifier 'control' ignored (in ignored keynames={'Control_R', 'Control_L'}) filtered_modifiers_set(['control'])=set() filtered_modifiers_set([])=set() handle_key((3, False, 'Control_L', 65507, 37, (), True, True)) handle keycode unpressing 37: key 'Control_L' fake_key(37, False)
- control-right showed the exact same pattern:
set_keyboard_layout_group(0) config=KeyboardConfig(gb / / None), current keyboard group=0 get_keycode(163, Control_R, ('control',))=105 (level=0) process_key_action(['key-action', 3, b'Control_R', True, (b'control',), 65508, b'', 163, 0]) server keycode=105 filtered_modifiers_set([])=set() modifier 'control' ignored (in ignored keynames={'Control_R', 'Control_L'}) filtered_modifiers_set(('control',))=set() handle_key((3, True, 'Control_R', 65508, 105, ('control',), True, True)) handle keycode pressing 105: key 'Control_R' fake_key(105, True) set_keyboard_layout_group(0) config=KeyboardConfig(gb / / None), current keyboard group=0 process_key_action(['key-action', 3, b'Control_R', False, (), 65508, b'', 163, 0]) server keycode=105 modifier 'control' ignored (in ignored keynames={'Control_R', 'Control_L'}) filtered_modifiers_set(['control'])=set() filtered_modifiers_set([])=set() handle_key((3, False, 'Control_R', 65508, 105, (), True, True)) handle keycode unpressing 105: key 'Control_R' fake_key(105, False)
So everything looks correct to me.
I suspect that either:
- you're using a different keyboard layout (see wiki/Keyboard for extra details to provide so that I can reproduce)
- or maybe you're interested in some specific key combinations with control held? If so, which ones?
Or both.
In any case, I've tried control-c + control-v using abiword and gedit, and that worked fine.
I also verified using xpra keyboard-test
that the correct modifier was set ("C" for "Control"), everything looks ok to me.
comment:7 Changed 13 months ago by
Maybe this is a keyboard layout issue, a bug has just been fixed for correct keyboard layout detection under mswindows: #2560.
So perhaps the latest beta builds will fix things for you? https://xpra.org/beta/windows.
If not, then I'm out of ideas. Bugs I cannot reproduce, I usually cannot fix.
comment:8 Changed 13 months ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
The only current problem with control is right-control not working in remote desktop. But that turns out to not be your fault. I just found the same behavior without xpra. So it's my Linux client, remmina that's to blame. So thanks for the earlier fixes when there was a problem, and sorry for not doing what should have been an obvious test until now.
comment:10 Changed 5 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2478
I can reproduce the problem, here's the client's
-d win32,keyboard
log output as I press and release theControl_L
key: