-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ALTGr key does not work properly in Linux with a Portuguese keyboard (with possible workaround) #1224
Comments
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 EN_us (Client, Windows 10) -> KB German (Host, Windows 11): Regular German layout with AltGr 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. |
This comment was marked as spam.
This comment was marked as spam.
You had 100 days to comment... |
What to write if nothing is new ? BtW, same pb between Windows and Linux here, both azerty keyboards. |
Literally anything...
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 |
Did you try use br-abnt2 keymap? |
same here, windows client on linux host, with both azerty keyboards |
Same here. 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 I had a look at Sunshine's debug log. Here's an annotated excerpt:
Moonlight (Windows) is sending a combination of A2 (left Ctrl) and A5 (right Alt). For this decoding, see here: Sunshine/src/platform/linux/input.cpp Lines 289 to 292 in 7e26d2f
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:
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 |
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
enter the following
install a systemdservice at reboot and enjoy "working" AltGr |
Thank you @Stephan3 , I just tried your workaround connecting from a Windows client to a EDIT: Sorry, I compiled it from the container, but executed it from outside. The container does not have permissions to access /dev/input |
Thank you @Stephan3 , working like a charm. |
Also thanks @Stephan3, you are a genius. |
It seems this issue hasn't had any activity in the past 90 days. If it's still something you'd like addressed, please let us know by leaving a comment. Otherwise, to help keep our backlog tidy, we'll be closing this issue in 10 days. Thanks! |
This issue was closed because it has been stalled for 10 days with no activity. |
Is there an existing issue for this?
Is your issue described in the documentation?
Is your issue 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
Apps
No response
Relevant log output
The text was updated successfully, but these errors were encountered: