Xpra trac archive

Xpra: Ticket #2478: Problems sending control characters

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.


Fri, 08 Nov 2019 08:14:20 GMT - Antoine Martin: keywords, priority, status changed

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

Fri, 08 Nov 2019 15:45:02 GMT - Antoine Martin: owner, status changed

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?

Sat, 09 Nov 2019 03:26:47 GMT - Bob Babcock:

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.

Mon, 11 Nov 2019 05:18:03 GMT - Bob Babcock:

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.

Sat, 30 Nov 2019 07:48:46 GMT - Bob Babcock: priority changed

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.

Sat, 30 Nov 2019 12:16:52 GMT - Antoine Martin: attachment set

keyboard-test showing both control-left and control-right events

Sat, 30 Nov 2019 12:32:28 GMT - Antoine Martin:

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: keyboard-test showing both control-left and control-right events

Then I enabled -d keyboard debugging (actually, I modified my running server with: xpra control :2 debug enable keyboard).

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.

Thu, 23 Jan 2020 08:43:46 GMT - totaamwin32:

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.

Sun, 26 Jan 2020 00:13:34 GMT - Bob Babcock: status changed; resolution set

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.

Sun, 26 Jan 2020 04:06:14 GMT - Antoine Martin:

FYI: other recent keyboard fixes in #2560.

Sat, 23 Jan 2021 05:52:23 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2478