With layout set to gr (locally/remote), there are warning errors (and keys don't pass through)

[stdedos]

Describe the bug

"Xpra-x86_64_6.0-r35620\xpra_cmd" shadow ssh://user@ip/1 --ssh="plink -ssh -agent" --modal-windows=no --headerbar=off --title="@title@ on @@/@server-display@" --encodings=-webp --microphone=off --speaker=off --webcam=no --pulseaudio=no --opengl=no --min-speed=70 --key-shortcut=Shift+F2:toggle_pointer_grab

XPRA_EXECUTABLE=Xpra-x86_64_6.0-r35620

2024-05-04 12:06:54,323 Xpra GTK3 client version 6.0-r35620 (g79036646b) beta
2024-05-04 12:06:54,563  running on Microsoft Windows Microsoft Windows 10 Enterprise
2024-05-04 12:06:54,563  cpython 3.11
2024-05-04 12:06:55,064 GStreamer version 1.24.1
2024-05-04 12:06:55,081 created named pipe 'Xpra\26052'
2024-05-04 12:06:55,258 Error setting up the pipeline:
2024-05-04 12:06:55,259  gst_parse_error: could not link decoder to sink (3)
2024-05-04 12:06:55,259  GStreamer pipeline for:
2024-05-04 12:06:55,259   appsrc name=src emit-signals=1 block=0 is-live=1 do-timestamp=1 stream-type=0 format=2 caps=video/x-h264,width=128,height=128,profile=(string)main,stream-format=(string)byte-stream,alignment=(string)au ! \
2024-05-04 12:06:55,259   d3d11h264dec name=decoder ! \
2024-05-04 12:06:55,259   appsink name=sink emit-signals=1 max-buffers=10 drop=False sync=False async=True qos=False caps=video/x-raw,width=128,height=128,format=(string)I420
2024-05-04 12:06:55,260 Error creating context h264 128x128 YUV420P
2024-05-04 12:06:55,260 gstreamer: h264 decoding failed: failed to setup gstreamer pipeline
2024-05-04 12:06:55,265 keyboard layout 'United States - English' : 'us' (0x409)
2024-05-04 12:06:55,359  keyboard settings: layout=us
2024-05-04 12:06:55,361  desktop size is 4480x1516:
2024-05-04 12:06:55,361   Default (1185x401 mm - DPI: 96x96) workarea: 4480x1476
2024-05-04 12:06:55,361     Samsung C32JG5x  2560x1440 at    0x0    (697x392 mm - DPI: 93x93) workarea: 2560x1400
2024-05-04 12:06:55,361     LG IPS234        1920x1080 at 2560x436  (510x290 mm - DPI: 96x95) workarea: 1920x1040 at 2560x436
2024-05-04 12:06:59,812 enabled remote logging
2024-05-04 12:06:59,814 Xpra shadow server version 5.0
2024-05-04 12:06:59,814  remote desktop size is 1920x1200
2024-05-04 12:06:59,815   :1.0 (508x318 mm - DPI: 96x96) workarea: 1848x1173 at   72x27
2024-05-04 12:06:59,815     LGD eDP-1        (336x210 mm - DPI: 145x145)
2024-05-04 12:07:00,182 running, 1 windows
...
2024-05-04 12:28:01,119 Warning: failed to parse string for key
2024-05-04 12:28:01,120  keyname=Greek_mu, keycode=77
2024-05-04 12:28:01,120  'utf-8' codec can't decode byte 0xec in position 0: unexpected end of data
2024-05-04 12:28:01,384 keyboard layout 'Greek' : 'gr' (0x408)
2024-05-04 12:28:01,398 keymap has been changed to 'gr'
2024-05-04 12:28:01,400  sending updated mappings to the server
2024-05-04 12:28:01,410 Warning: failed to parse string for key
2024-05-04 12:28:01,411  keyname=Greek_UPSILON, keycode=89
2024-05-04 12:28:01,411  'utf-8' codec can't decode byte 0xd5 in position 0: unexpected end of data
2024-05-04 12:28:01,481 Warning: failed to parse string for key
2024-05-04 12:28:01,482  keyname=Greek_upsilon, keycode=89
2024-05-04 12:28:01,482  'utf-8' codec can't decode byte 0xf5 in position 0: invalid start byte

To Reproduce Steps to reproduce the behavior:

1. server command
2. client command
3. specific action to trigger the bug

System Information (please complete the following information):

• Server OS: Ubuntu 20.04.6 LTS
• Client OS: Microsoft Windows [Version 10.0.18363.836]
• Xpra Server Version: (see above)
• Xpra Client Version: (see above)

Additional context Add any other context about the problem here. Please see "reporting bugs" in the wiki section.

[totaam]

That's not easy unfortunately! This commit d49e84f3b9cafbc61b728c4e06d0583daf047482 (6 years ago) added a workaround for Gtk failing to convert the event key string into something we can use without throwing an exception. It remains in use to this day...

We could generate our own map, or perhaps change the server code to do the lookup based on Greek_UPSILON alone, without using the string representation. Either way, I'm not sure how to convert Greek_UPSILON to a string automatically.

[stdedos]

It might have to do something with how the keys end up on the server - and somehow its keyboard language is changed

Some Alt, Shift shortcuts don't pass cleanly, e.g. Alt+` to cycle windows. That usually leaves Alt activated on the remote side, even if I have released the keys locally. "Somehow then", it ends up triggering a layout change on the remote - causing the issue that local en/gr keys cannot be then "sent over" to the server.

But if it's that complex, let's leave it. I'd be nice if yet-again modifier keys would be passed on / reflected cleanly on the remote. However, "even that is broken" since, activating Alt+Shift as a language-changer, it blocks any Ctrl+Alt+Shift shortcut (and similarly, using Ctrl to "find mouse" also does "something else")

[totaam]

The key parsing issue is also recorded in https://github.com/Xpra-org/xpra/issues/4265#issuecomment-2198053577

[stdedos]

Yeah, it is the same. Let's just ignore it, I guess 😕

[totaam]

Let's not. We should be able to figure out the actual key from the keyname, ie: Greek_UPSILON. We just need to find a mapping somewhere from the key name to a key string. Or server-side, to a key sym or key code.

[stdedos]

Idk. Isn't it possible to get which key was pressed - like coordinates? Then you just "press the key" which corresponds to those coordinates.

e.g.: Pressing Ö on the German keyboard

Reflects to ; in US

---

Of course my suggestion is naive. You have to assume "same-kb layout" (ANSI/ISO), and if they keyboard "looks alike" (e.g., some kbs have some variant of / key next to the LShift - what do you do with that key?)

... and of course that you can "decide" server's kb.

But I just wanted to write this out.

[totaam]

Idk. Isn't it possible to get which key was pressed - like coordinates?

The closest thing you will find is the keycode. Unfortunately, that's already been cooked by whatever software layers sit between your keyboard controller and the OS then X11 (ie: evdev). Assuming that you run an X11 client, you can try the --keyboard-raw=yes switch which will send and process all keyboard events untranslated. Assuming that the keyboard was detected correctly (and that's not easy at all) and mirrored correctly (also not easy) then this should give more or less the same result as local applications. Caveats: some keys are intercepted by the OS / X11, modifier keys (..), sticky keys, remapped keys, etc. Other platforms have completely different keycodes, so that's a non-starter.

[stdedos]

Okay, so - impossible 😅 🙃

At least "my constant purpose" of being able to work on my Linux laptops via my desktop (without using kvms, docking stations etc etc).

[totaam]

Closing in favour of #4265 which has more details.