Problems sending control characters

[Bob Babcock]

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.

[Antoine Martin]

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

[Antoine Martin]

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?

[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.

[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.

[Bob Babcock]

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.

[Antoine Martin]

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

[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:

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.

[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.

[Bob Babcock]

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.

[Antoine Martin]

FYI: other recent keyboard fixes in #2560.

[migration script]

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