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.
I can reproduce the problem, here's the client's -d win32,keyboard
log output as I press and release the Control_L
key:
client 1 @32.505 mask_to_names(<flags GDK_CONTROL_MASK of type Gdk.ModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['control', 'mod2'] client 1 @32.506 parse_key_event(<Gdk.EventKey object at 0x04a46e88 (void at 0x1be57590)>, True)=<GTKKeyEvent object, contents: {'modifiers': ['control', 'mod2'], 'keyname': 'Control_L', 'keyval': 65507, 'keycode': 17, 'group': 0, 'string': '', 'pressed': True}> client 1 @32.506 handle_key_action(ClientWindow(2), <GTKKeyEvent object, contents: {'modifiers': ['control', 'mod2'], 'keyname': 'Control_L', 'keyval': 65507, 'keycode': 17, 'group': 0, 'string': '', 'pressed': True}>) wid=2 client 1 @32.507 key_handled_as_shortcut: shortcut(Control_L)=None client 1 @32.507 process_key_event: Control_L pressed=True, with GetKeyState(VK_RMENU)=0 client 1 @32.562 send_delayed_key() delayed_event=(<bound method KeyboardHelper.send_key_action of <xpra.client.gtk_base.gtk_keyboard_helper.GTKKeyboardHelper object at 0x038d0628>>, 2, <GTKKeyEvent object, contents: {'modifiers': ['control', 'mod2'], 'keyname': 'Control_L', 'keyval': 65507, 'keycode': 17, 'group': 0, 'string': '', 'pressed': True}>) client 1 @32.565 send_delayed_key() GetKeyState(VK_RMENU)=0 client 1 @32.600 mask_to_names(<flags 0 of type Gdk.ModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['mod2'] client 1 @32.600 parse_key_event(<Gdk.EventKey object at 0x04a46d20 (void at 0x1be57590)>, False)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'keyname': 'Control_L', 'keyval': 65507, 'keycode': 17, 'group': 0, 'string': '', 'pressed': False}> client 1 @32.600 handle_key_action(ClientWindow(2), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'keyname': 'Control_L', 'keyval': 65507, 'keycode': 17, 'group': 0, 'string': '', 'pressed': False}>) wid=2 client 1 @32.600 key_handled_as_shortcut: shortcut(Control_L)=None client 1 @32.600 process_key_event: Control_L pressed=False, with GetKeyState(VK_RMENU)=0 client 1 @32.601 send_delayed_key() delayed_event=None client 1 @32.601 send_key_action(2, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'keyname': 'Control_L', 'keyval': 65507, 'keycode': 17, 'group': 0, 'string': '', 'pressed': False}>) set_keyboard_layout_group(0) config=KeyboardConfig(gb / / None), current keyboard group=0 process_key_action(['key-action', 2, b'Control_L', False, (b'mod2',), 65507, b'', 17, 0]) server keycode=37 filtered_modifiers_set(['mod2'])={'mod2'} filtered_modifiers_set(('mod2',))={'mod2'} handle_key((2, False, 'Control_L', 65507, 37, ('mod2',), True, True)) handle keycode 37: key Control_L was already unpressed, ignoring
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?
I'm traveling and won't be able to do RDP testing until Sunday evening. I do verify that with r24414 the keyboard test now sees both control keys. The only r24414 version I see is 4.x. I had been using the 3.x series; I never ran the 4.x keyboard test before.
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.
With 4.0.0-r24461 on Windows, v4.0-r24529 on Fedora 31, current status in a remmina remote desktop session is left control works, right control doesn't. That's all I need, so I changed the priority to minor.
keyboard-test showing both control-left and control-right events
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
).
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)
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:
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.
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.
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.
FYI: other recent keyboard fixes in #2560.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2478