xpra icon
Bug tracker and wiki

Opened 2 weeks ago

Last modified 11 days ago

#2478 new defect

Problems sending control characters

Reported by: Bob Babcock Owned by: Bob Babcock
Priority: critical 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.

Change History (4)

comment:1 Changed 2 weeks ago by Antoine Martin

Keywords: win32 added
Priority: majorcritical
Status: newassigned

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

comment:2 Changed 2 weeks ago by Antoine Martin

Owner: changed from Antoine Martin to Bob Babcock
Status: assignednew

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 2 weeks ago by 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.

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

Note: See TracTickets for help on using tickets.