Xpra: Ticket #2751: Keyboard state too gives different output

On

"Xpra-Python3-x86_64_4.0-r26160\xpra_cmd" attach ssh://user@ip/2 \
    --ssh="plink -ssh -agent" --modal-windows=no \
    --title="@title@ on @hostname@/@server-display@" \
    --opengl=no --bandwidth-limit=6Mbps
2020-05-04 11:33:22,104 Xpra GTK3 client version 4.0-r26160 64-bit
2020-05-04 11:33:22,106  running on Microsoft Windows 10
2020-05-04 11:33:22,180 Warning: failed to import opencv:
2020-05-04 11:33:22,180  No module named 'cv2'
2020-05-04 11:33:22,181  webcam forwarding is disabled
2020-05-04 11:33:22,857 GStreamer version 1.16.2 for Python 3.8.2 64-bit
2020-05-04 11:33:23,104 keyboard layout code 0x409
2020-05-04 11:33:23,104 identified as 'United States - English' : us
2020-05-04 11:33:23,423  keyboard settings: layout=us
2020-05-04 11:33:23,426  desktop size is 4160x1440 with 1 screen:
2020-05-04 11:33:23,426   Default (1100x381 mm - DPI: 96x96) workarea: 4160x1400
2020-05-04 11:33:23,426     Generic PnP Monitor 1600x900 at 0x534 (309x174 mm - DPI: 131x131) workarea: 1600x860
2020-05-04 11:33:23,426     C32JG5x 2560x1440 at 1600x0 (697x392 mm - DPI: 93x93) workarea: 2560x1400
2020-05-04 11:33:28,921 enabled remote logging
2020-05-04 11:33:28,923 Xpra GTK3 X11 server version 3.0.9-r26081 64-bit
2020-05-04 11:33:28,924  running on Linux Ubuntu 16.04 xenial

It seems to me that I cannot send the Ctrl+Alt+E shortcut.

I was trying to debug this, but it seems like I am getting different output between the server and the client.

Is this expected? Is the server receiving the shortcut alright or not?



Mon, 04 May 2020 10:20:02 GMT - stdedos: attachment set


Mon, 04 May 2020 10:53:09 GMT - Antoine Martin: owner, description changed

I believe that [2] is NumLock and can be ignored (feel free to check with xmodmap -pm), 0xFFFFFF is a spurious key event with no real key so we can't simulate it.

Looks OK to me.


Mon, 04 May 2020 11:17:18 GMT - stdedos: summary changed


Mon, 04 May 2020 11:20:54 GMT - Antoine Martin: summary changed

(For educational purposes) What does that mean? I didn't press anything else - why is that registering?

What is Win32 virtual key code 0xFF used for and is it documented somewhere?

I tried to follow this...

If there are keyboard problems, let's cut out the middleman and deal with it, that is: without adding another piece of software into the puzzle. Keyboard mapping is hard enough as it is.


Mon, 04 May 2020 11:21:31 GMT - Antoine Martin:

(For educational purposes) What does that mean? I didn't press anything else - why is that registering?

What is Win32 virtual key code 0xFF used for and is it documented somewhere?

I tried to follow this...

If there are keyboard problems, let's cut out the middleman and deal with it, that is: without adding another piece of software into the puzzle. Keyboard mapping is hard enough as it is.


Mon, 04 May 2020 11:39:21 GMT - stdedos: owner changed

If by the GTK keyboard output you concur that the key is replayed normally, then I am fine closing this as-is.

My original issue is that the Ctrl+Alt+E is not doing alias-expansion in bash. I suspected that something, between my hardware keyboard and the bash shell I have is not playing the shortcut. Since there were obscure keyboard issues with xpra before, I thought of this.


In any case - I found the issue: I have registered ^!e::€ as a Hotkey in AutoHotkey (https://www.autohotkey.com/docs/Hotstrings.htm, but that's "internal AHK discussion") Due to internal workings (and having other Hotstrings in the same script), AHK registers the installation of the keyboard hook https://www.autohotkey.com/docs/commands/_InstallKeybdHook.htm (hence the spurious key event).

Using a different remote access software, the replacement is sent correctly. When the shortcut is disabled, everything works as normal via both ways.


Totally up to you if you are interested in this or dismiss it. Thank you for your very quick response :-D


Mon, 04 May 2020 11:42:06 GMT - Antoine Martin: status changed; resolution set

... then I am fine closing this as-is.

Closing.

Totally up to you if you are interested in this or dismiss it.

Feel free to create a new ticket for this, but I have no idea how we're supposed to handle a key event we don't receive using the existing GTK API..


Mon, 04 May 2020 11:52:22 GMT - stdedos:

You could've repurposed this one in that case 😕 In any case: Enhancement on #2752


Sat, 23 Jan 2021 05:59:46 GMT - migration script:

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