xpra icon
Bug tracker and wiki

Opened 3 months ago

Closed 3 months ago

Last modified 3 months ago

#2751 closed defect (invalid)

Keyboard state too gives different output

Reported by: stdedos Owned by: Antoine Martin
Priority: minor Milestone: 4.0
Component: client Version: 3.0.x
Keywords: Cc:

Description (last modified by Antoine Martin)

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?

Attachments (1)

Xpra_keyboard-tool-different-output_cmd_2020-05-04_13-15-06.png (36.0 KB) - added by stdedos 3 months ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 3 months ago by Antoine Martin

Description: modified (diff)
Owner: changed from Antoine Martin to stdedos

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.

comment:3 Changed 3 months ago by stdedos

Summary: Keyboard state too gives different outputKeyboard state tool gives different output

comment:4 Changed 3 months ago by Antoine Martin

Summary: Keyboard state tool gives different outputKeyboard state too gives different output

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

comment:5 Changed 3 months ago by 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.

comment:6 Changed 3 months ago by stdedos

Owner: changed from stdedos to Antoine Martin

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/Hotkeys.htm) (i.e. when Ctrl+Alt+E is pressed, give instead (this would be more like a "Hotstring" 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

Last edited 3 months ago by stdedos (previous) (diff)

comment:7 Changed 3 months ago by Antoine Martin

Resolution: invalid
Status: newclosed

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

comment:8 Changed 3 months ago by stdedos

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

Note: See TracTickets for help on using tickets.