Sunshine
Sunshine copied to clipboard
LizardByte
ALTGr key does not work properly in Linux with a Portuguese keyboard (with possible workaround)
Is there an existing issue for this?
- [X] I have searched the existing issues
Is your issue described in the documentation?
- [X] I have read the documentation
Is your issue present in the nightly release?
- [X] This issue is present in the nightly release
Describe the Bug
On a Portuguese keyboard the AltGr (modcode 165) key does not work in Linux (but it works in Windows). When pressing Altgr (from moonlight) it generates two key presses, modcode 162 (left control) and then modcode 165. I have a workaround but I am not sure if it is the correct one: if(modcode == 165){ if(lastmodcode == 162){ libevdev_uinput_write_event(keyboard, EV_MSC, MSC_SCAN, keysym(lastmodcode).keycode); libevdev_uinput_write_event(keyboard, EV_KEY,keysym(lastmodcode).keycode , 0); libevdev_uinput_write_event(keyboard, EV_SYN, SYN_REPORT, 0); } } So basically, I just simulate a keyup event on 162 if the current modccode is 165, and it works.
Expected Behavior
The AtlGr should only correspond to Linux's iso_level3_shift.
Additional Context
No response
Host Operating System
Linux
Operating System Version
Ubuntu 22.04
Architecture
64 bit
Sunshine commit or version
0.19.1
Package
Linux - deb
GPU Type
Nvidia
GPU Model
3090
GPU Driver/Mesa Version
nvidia 525
Capture Method (Linux Only)
No response
Config
min_threads = 4
nv_preset = p1
Apps
No response
Relevant log output
[2023:04:27:01:37:54]: Info: Sunshine version: 0.19.1
[2023:04:27:01:37:54]: Warning: Couldn't find app image at path [desktop.png]
[2023:04:27:01:37:54]: Warning: Couldn't find app image at path [desktop.png]
[2023:04:27:01:37:54]: Warning: Couldn't find app image at path [steam.png]
[2023:04:27:01:37:55]: Error: Failed to create session: This hardware does not support NvFBC
[2023:04:27:01:37:55]: Error: Failed to gain CAP_SYS_ADMIN
[2023:04:27:01:37:55]: Error: Failed to gain CAP_SYS_ADMIN
[2023:04:27:01:37:55]: Error: Environment variable WAYLAND_DISPLAY has not been defined
[2023:04:27:01:37:55]: Info: Detecting monitors
[2023:04:27:01:37:55]: Info: Detected monitor 0: DP-0, connected: true
[2023:04:27:01:37:55]: Info: Detected monitor 1: DP-1, connected: false
[2023:04:27:01:37:55]: Info: Detected monitor 2: HDMI-0, connected: false
[2023:04:27:01:37:55]: Info: Detected monitor 3: DP-2, connected: false
[2023:04:27:01:37:55]: Info: Detected monitor 4: DP-3, connected: false
[2023:04:27:01:37:55]: Info: Detected monitor 5: HDMI-1, connected: false
[2023:04:27:01:37:55]: Info: Detected monitor 6: DP-4, connected: false
[2023:04:27:01:37:55]: Info: Detected monitor 7: DP-5, connected: false
[2023:04:27:01:37:55]: Info: Detected monitor 8: DP-1-0, connected: false
[2023:04:27:01:37:55]: Info: Detected monitor 9: DP-1-1, connected: false
[2023:04:27:01:37:55]: Info: Detected monitor 10: HDMI-1-0, connected: false
[2023:04:27:01:37:55]: Info: Detected monitor 11: DP-1-2, connected: false
[2023:04:27:01:37:55]: Info: Detected monitor 12: DP-1-3, connected: false
[2023:04:27:01:37:55]: Info: Detected monitor 13: HDMI-1-1, connected: false
[2023:04:27:01:37:55]: Info: Detected monitor 14: DP-1-4, connected: false
[2023:04:27:01:37:55]: Info: Detected monitor 15: DP-1-5, connected: false
[2023:04:27:01:37:55]: Info: // Testing for available encoders, this may generate errors. You can safely ignore those errors. //
[2023:04:27:01:37:55]: Info: Trying encoder [nvenc]
[2023:04:27:01:37:55]: Info: Screencasting with X11
[2023:04:27:01:37:55]: Info: SDR color coding [Rec. 601]
[2023:04:27:01:37:55]: Info: Color range: [JPEG]
[2023:04:27:01:37:55]: Info: Screencasting with X11
[2023:04:27:01:37:55]: Info: SDR color coding [Rec. 601]
[2023:04:27:01:37:55]: Info: Color range: [JPEG]
[2023:04:27:01:37:55]: Info: Screencasting with X11
[2023:04:27:01:37:55]: Info: SDR color coding [Rec. 601]
[2023:04:27:01:37:55]: Info: Color range: [JPEG]
[2023:04:27:01:37:55]: Info: Screencasting with X11
[2023:04:27:01:37:55]: Info: SDR color coding [Rec. 601]
[2023:04:27:01:37:55]: Info: Color range: [JPEG]
[2023:04:27:01:37:55]: Info: Screencasting with X11
[2023:04:27:01:37:55]: Info: SDR color coding [Rec. 601]
[2023:04:27:01:37:55]: Info: Color range: [JPEG]
[2023:04:27:01:37:55]: Info: Screencasting with X11
[2023:04:27:01:37:55]: Info: SDR color coding [Rec. 709]
[2023:04:27:01:37:55]: Info: Color range: [JPEG]
[2023:04:27:01:37:55]: Error: Could not open codec [h264_nvenc]: Function not implemented
[2023:04:27:01:37:55]: Info: Screencasting with X11
[2023:04:27:01:37:55]: Info: SDR color coding [Rec. 709]
[2023:04:27:01:37:55]: Info: Color range: [JPEG]
[2023:04:27:01:37:55]: Error: cuda::cuda_t doesn't support any format other than AV_PIX_FMT_NV12
[2023:04:27:01:37:55]: Info: Screencasting with X11
[2023:04:27:01:37:55]: Info: SDR color coding [Rec. 601]
[2023:04:27:01:37:55]: Info: Color range: [JPEG]
[2023:04:27:01:37:55]: Info: Screencasting with X11
[2023:04:27:01:37:55]: Info: SDR color coding [Rec. 601]
[2023:04:27:01:37:55]: Info: Color range: [JPEG]
[2023:04:27:01:37:55]: Warning: nvenc: hevc: replacing nalu prefix data
[2023:04:27:01:37:55]: Info:
[2023:04:27:01:37:55]: Info: // Ignore any errors mentioned above, they are not relevant. //
[2023:04:27:01:37:55]: Info:
[2023:04:27:01:37:55]: Info: Found encoder nvenc: [h264_nvenc, hevc_nvenc]
[2023:04:27:01:37:55]: Info: Adding avahi service Sunshine
[2023:04:27:01:37:55]: Info: Configuration UI available at [https://localhost:47990]
[2023:04:27:01:37:55]: Info: Avahi service name collision, renaming service to Sunshine #2
[2023:04:27:01:37:55]: Info: Adding avahi service Sunshine #2
[2023:04:27:01:37:57]: Info: Avahi service Sunshine #2 successfully established.
[2023:04:27:01:38:06]: Info: Executing [Desktop]
[2023:04:27:01:38:06]: Info: CLIENT CONNECTED
[2023:04:27:01:38:06]: Info: Detecting monitors
[2023:04:27:01:38:06]: Info: Detected monitor 0: DP-0, connected: true
[2023:04:27:01:38:06]: Info: Detected monitor 1: DP-1, connected: false
[2023:04:27:01:38:06]: Info: Detected monitor 2: HDMI-0, connected: false
[2023:04:27:01:38:06]: Info: Detected monitor 3: DP-2, connected: false
[2023:04:27:01:38:06]: Info: Detected monitor 4: DP-3, connected: false
[2023:04:27:01:38:06]: Info: Detected monitor 5: HDMI-1, connected: false
[2023:04:27:01:38:06]: Info: Detected monitor 6: DP-4, connected: false
[2023:04:27:01:38:06]: Info: Detected monitor 7: DP-5, connected: false
[2023:04:27:01:38:06]: Info: Detected monitor 8: DP-1-0, connected: false
[2023:04:27:01:38:06]: Info: Detected monitor 9: DP-1-1, connected: false
[2023:04:27:01:38:06]: Info: Detected monitor 10: HDMI-1-0, connected: false
[2023:04:27:01:38:06]: Info: Detected monitor 11: DP-1-2, connected: false
[2023:04:27:01:38:06]: Info: Detected monitor 12: DP-1-3, connected: false
[2023:04:27:01:38:06]: Info: Detected monitor 13: HDMI-1-1, connected: false
[2023:04:27:01:38:06]: Info: Detected monitor 14: DP-1-4, connected: false
[2023:04:27:01:38:06]: Info: Detected monitor 15: DP-1-5, connected: false
[2023:04:27:01:38:06]: Info: Screencasting with X11
[2023:04:27:01:38:06]: Info: Configuring selected monitor (0) to stream
[2023:04:27:01:38:06]: Info: Streaming display: DP-0 with res 1920x1080 offset by 0x0
[2023:04:27:01:38:06]: Info: SDR color coding [Rec. 601]
[2023:04:27:01:38:06]: Info: Color range: [MPEG]
[2023:04:27:01:38:06]: Info: Setting default sink to: [sink-sunshine-stereo]
[2023:04:27:01:38:06]: Info: Found default monitor by name: sink-sunshine-stereo.monitor
Same goes for moonlight-qt (Raspberry Pi) client and Sunshine (Windows) host. German keyboard in this instance, if it matters.
Really interested in this aswell. Here is some tests I did:
KB German (Client, Windows 10) -> KB German (Host, Windows 11): Regular German layout with AltGr KB German (Client, Windows 10) -> KB German (Host, Arch Linux): Blocks input, nothing happens KB German (Client, Windows 10) -> KB EN_us (Host, Windows 11): AltGr key behaves as Ctrl, US layout KB German (Client, Windows 10) -> KB EN_us (Host, Arch Linux): AltGr key behaves as Ctrl, US layout
KB EN_us (Client, Windows 10) -> KB German (Host, Windows 11): Regular German layout with AltGr KB EN_us (Client, Windows 10) -> KB German (Host, Arch Linux): Regular German layout with AltGr KB EN_us (Client, Windows 10) -> KB EN_us (Client, Windows 11): Acts as Alt Key, Regular US layout KB EN_us (Client, Windows 10) -> KB EN_us (Client, Arch Linux): AltGr does nothing, German layout
Maybe this helps to confirm the thesis or at least help someone figure out what exactly needs to be done.
This issue is stale because it has been open for 90 days with no activity. Comment or remove the stale label, otherwise this will be closed in 10 days.
This issue was closed because it has been stalled for 10 days with no activity.
What to write if nothing is new ?
BtW, same pb between Windows and Linux here, both azerty keyboards.
Literally anything...
Bump
Is usually sufficient.
I'll re-open this, but it doesn't guarantee anyone will work on a fix. Best way to get something fixed is to open a PR with the corrections made.
i had this same problem note: i am using a windows client and a linux server
Same here. Host: Ubuntu 22.04, Sunshine 0.22 Client: Win10, Moonlight 5.0.1 Host and client use Swiss French layout.
The affected symbols include: @ # | ~ [ ] { } €
In other words Sunshine is fabulous for gaming with a gamepad, but not for entering passwords, typing console commands or general remote desktop usage. (This all depends on the keyboard layout of course, the Swiss French one may be particularly affected.)
I've just posted my own investigation on moonlight's tracker. For simplicity's sake I re-post it here in its entirety. I hope that's fine. It does have some additional technical details that could turn out to be useful.
I can provide some more details. On my keyboard (configured as Swiss French on both Ubuntu host and Windows 10 client) the ~ is entered using the AltGr key. As I learned just now, this key does not exist on a US keyboard, which has a second Alt key. For me all the characters that use AltGr are broken. (Notably € | @ # ° § | ~ [ ] { } \ )
I had a look at Sunshine's debug log. Here's an annotated excerpt:
# left Ctrl
[2024:04:09:12:33:54]: Debug: --begin keyboard packet--
keyAction [00000003]
keyCode [80A2]
modifiers [02]
flags [00]
--end keyboard packet--
[2024:04:09:12:33:54]: Debug: --begin keyboard packet--
keyAction [00000004]
keyCode [80A2]
modifiers [00]
flags [00]
# (left) Alt
--end keyboard packet--
[2024:04:09:12:34:04]: Debug: --begin keyboard packet--
keyAction [00000003]
keyCode [80A4]
modifiers [04]
flags [00]
--end keyboard packet--
[2024:04:09:12:34:04]: Debug: --begin keyboard packet--
keyAction [00000004]
keyCode [80A4]
modifiers [00]
flags [00]
--end keyboard packet--
# AltGr (at the physical location where the US keyboard has a second Alt key)
[2024:04:09:12:34:11]: Debug: --begin keyboard packet--
keyAction [00000003]
keyCode [80A2]
modifiers [02]
flags [00]
--end keyboard packet--
[2024:04:09:12:34:11]: Debug: --begin keyboard packet--
keyAction [00000003]
keyCode [80A5]
modifiers [06]
flags [00]
--end keyboard packet--
[2024:04:09:12:34:11]: Debug: --begin keyboard packet--
keyAction [00000004]
keyCode [80A2]
modifiers [04]
flags [00]
--end keyboard packet--
[2024:04:09:12:34:11]: Debug: --begin keyboard packet--
keyAction [00000004]
keyCode [80A5]
modifiers [00]
flags [00]
--end keyboard packet--
# Ctrl
[2024:04:09:12:34:16]: Debug: --begin keyboard packet--
keyAction [00000003]
keyCode [80A3]
modifiers [02]
flags [00]
--end keyboard packet--
[2024:04:09:12:34:16]: Debug: --begin keyboard packet--
keyAction [00000004]
keyCode [80A3]
modifiers [00]
flags [00]
--end keyboard packet--
Moonlight (Windows) is sending a combination of A2 (left Ctrl) and A5 (right Alt). For this decoding, see here:
https://github.com/LizardByte/Sunshine/blob/7e26d2fd3064c6adf3e7a52a275046dd0cf194be/src/platform/linux/input.cpp#L289-L292
Apparently Windows interprets the combination of Ctrl+Alt as AltGr, which could explain why this issue specifically hits Linux servers. Also Gamestream is Windows-only. So this would even be "fine" protocol-wise in the original implementation.
What I find a bit puzzling is that in that list there is no specific entry for AltGr. (But I'm not an expert at keymaps, I just did some research.) Anyway, I think that for Linux hosts Moonlight could just send the specific AltGr code, if there is one, or Sunshine on Linux could re-interpret itself the combination of left Ctrl + right Alt as AltGR before emitting it as virtual input. (This would have the unfortunate side-effect of very slightly reducing the possible keymappings in games. AltGr and AltGr+Ctrl could no longer be differentiated?)
By googling I also found this:
// Windows does not have a specific key code for AltGr. We use the unused
// VK_OEM_AX to represent AltGr, matching the behaviour of Firefox on Linux.
VKEY_ALTGR = VK_OEM_AX,
https://chromium.googlesource.com/experimental/chromium/src/+/53.0.2785.12/ui/events/keycodes/keyboard_codes_win.h?autodive=0%2F%2F%2F%2F#186 Maybe it's useful in a future where compatibility with Gamestream is no longer a concern.
I remapped today the keypress in Manjaro and it worked.
Install evremap on your Linux host.(https://github.com/wez/evremap)
Edit the config file at
nano /etc/evremap.toml
enter the following
device_name = 'Keyboard passthrough'
[[remap]]
input = ["KEY_LEFTCTRL", "KEY_RIGHTALT"]
output = ["KEY_RIGHTALT"]
install a systemdservice at /usr/lib/systemd/system/evremap.service
enable it at boot systemd enable evremap
reboot and enjoy "working" AltGr
Thank you @Stephan3 , I just tried your workaround connecting from a Windows client to a ~~distrobox tumbleweed container in a~~ openSUSE Kalpa VM, and it works. This confirms what the problem and solution is.
EDIT: Sorry, I compiled it from the container, but executed it from outside. The container does not have permissions to access /dev/input
Also thanks @Stephan3, you are a genius. Using Sunshine on Fedora + Moonlight on Windows and it's also working like a charm.
