Keyboard layout incorrect and always EN/US [Translate Keyboard] US -> FR

[joueurgear]

hello, I would like to have the possibility to adjust the keyboard in azerty. I looked everywhere but in all my windows 10 the language is in french and Only one language is defined (for client and server sunshine). When I use sunshine, unable to adjust the keyboards other than in US according to sunshine I think?

anybody know how to just change that? To play: Z is used to forward or with the US keyboard the key is W

Setup : Radeon 580 RX Series + sunshine and client Windows 10 with Moonlight client

[joueurgear]

something like that, I am not c++ developer but I am learning Exactly, if it is possible to do could you compile it? Use LoadKeyboardLayout and send WM_INPUTLANGCHANGEREQUEST to change the keyboard layout as follows:

`#include #include #include <windows.h>

int main() { HKL hkl = LoadKeyboardLayout(L"0000080c", KLF_ACTIVATE); PostMessage(GetConsoleWindow(), WM_INPUTLANGCHANGEREQUEST, 0, (LPARAM)hkl); std::string str; while(std::cin >> str) if(str == "0") break; return 0; }`

[WisdomCode]

I can confirm similar behavior with DE keyboard settings, with Ubuntu 21.04 as well as Windows. I would really appreciate this getting fixed.

Edit: I got the Linux one Fixed by having multiple Keyboardlayouts installed. No idea why that does the trick, but it does, I suspect its due to the way gnome initializes the Desktop. There are however some Problems left, Windows doesnt do it that easy, I will follow up after some compiling some stuff, as I probably found the culprit.

[arixoneth]

Same here with Hungarian keyboard layout, plase fix the issue.

[WisdomCode]

Little update, again unfortunately only for Linux (I will look at windows next): I've committed a little change to the code for recognizing the missing Keyboard key responsible for <, | and > on the QWERTZ Layout (but also on others I strongly assume). https://github.com/loki-47-6F-64/sunshine/pull/207 Inside I've left some advice on how I gathered the information necessary to make this commit, so it can be replicated if you are new to this (like me). At least on Linux, I can't find any issues now. I've got an idea on where to start on Windows, and will try it out next time.

[WisdomCode]

The problem with Windows is that GeForce has a very weird way to apply the keycodes. Moonlight actually sends US-keys to sunshine, therefore the server has to revert the process on its side key by key. There is already an option for that: keybindings in the config. You can get the key thats puts in and replace it with the value you want out. Unfortunately, this is will be the only way to accomplish that (although such mappings could of course be provided by sunshine fitting to specific keyboard layouts, so a layout could be given in the settings instead of a weird list of hexadecimals).

This could be outsourced (like translations), but it will need some instructions for easy replication. I will look into that.

EDIT: To get a feeling for the keybindings (and a headsup for fellow users of the QWERTZ-Layout), the german keyboard can be achieved natively by writing the following keybindings in the sunshine.conf:

keybindings = [
   0x5a, 0x59,
   0x59, 0x5a,
   0xbd, 0xdb,
   0xdb, 0xba,
   0xba, 0xc0,
   0xc0, 0xdc,
   0xdc, 0xbf,
   0xbf, 0xbd,
   0xdd, 0xbb,
   0xbb, 0xdd
]

[WisdomCode]

Alright, I have created a (badly written) keylogger thats trivial enough to use. Just start the powershell script and it will put out the hexadecimal value of the every key you press. Using this information you can now create a keybinding fitting to your layout (and share it): present the keybindings in pairs (like I did in my previous post), the first being the key thats supposed to be replaced and the second the value it will be replaced with. For example, if you have a z key that returns y in sunshine, get the keycode of the key that wrongly returns the y and find the key with the according keycode that returns the z at the moment. now arrange them: KeyReturningY, KeyReturningZ, Rinse and repeat for all wrong values. Share so others don't have to do it. The script follows here (just copy the content into an empty textfile with the ending .ps1 and start it).

$Signature = '[DllImport("user32.dll")]public static extern short GetAsyncKeyState(int vKey);'
Add-Type -MemberDefinition $Signature -Name 'Win32GetAsyncKeyState' -Namespace Win32Functions

$cOld=0
while ($true) {
    for ($c = 1; $c -lt 255; $c++) { 
        $state = [Win32Functions.Win32GetAsyncKeyState]::GetAsyncKeyState($c);
        if ($state -ne 0 -and $c -ne $cOld) {
           echo "0x$([Convert]::ToString($c, 16))";
           $cOld=$c
        }
    }
    Start-Sleep 0.6
}

[arixoneth]

Thanks for the help, sadly there is an issue with this solution, it's that if you hold down the key(not just press it a single time) than the key stays the US not what you specified.

[WisdomCode]

Your right, haven't tested that! Strange, this is definitely a bug, I will look into why this happens, because strangely enough, although browsing through the input code for a while now, I cannot quite explain how that happens.

[WisdomCode]

See the pull request right now, this should fix it.

[Spl3en]

The latest version didn't fix it for me. Using Windows 11 and AZERTY layout registered on both devices.

Here's my keybindings in sunshine.conf in order to fix it :

keybindings = [
    # Old char, Char to map
    0x41, 0x51, # A
    0x51, 0x41, # Q
    0x57, 0x5A, # Z
    0x5A, 0x57, # W
    0x4D, 0xBC, # ,
    0xBA, 0x4D, # M
    0xBC, 0xBE, # ;
    0xBF, 0xDF, # !
    0xDE, 0xC0, # ù
    0xC0, 0xDE, # ²
    0xDB, 0xDD, # ^
    0xDD, 0xBA, # $
]

For some reason, I can't remap the ')' key. Everything else works.

[spali]

Only for documentation if someone else need it, Swiss German (de_CH) keyboard bindings:

keybindings = [
    0x5a, 0x59,
    0x59, 0x5a,
    0xbd, 0xdb,
    0xdb, 0xba,
    0xba, 0xde,
    0xc0, 0xbf,
    0xdc, 0xdf,
    0xbf, 0xbd,
    0xbb, 0xdd,
    0xdd, 0xc0,
    0xde, 0xdc,
]

BTW: The following makes it easy for (hopefully every keyboard layout)

1. Go to httpd://kbdlayout.info/
2. open "US Multinational Keyboard Layout"
3. open the link on the bottom "XML internal tables"
4. search for the tag <VSCtoVK> and get the context of it (a lot of hex values).
5. do the same with your keyboard layout
6. compare them in the exact order and all which start with 00 and are not the same on both lists, can be used as binding by replacing the 00 with 0x.

I used Excel format and compare the values and filter them only for the once that are not the same.

[Ambr051us]

Hungarian layout for documentation:

keybindings = [
   0x30, 0xc0,
   0xbd, 0xbf,
   0x59, 0x5a,
   0xc0, 0x30,
   0x5a, 0x59,
   0xbf, 0xbd
]

[sinoseque]

Spanish:

keybindings = [
	0xBA, 0xC0,
	0xDC, 0xBF,
	0xDB, 0xBA,
	0xDD, 0xBB,
	0xBD, 0xDB,
	0xBB, 0xDD,
	0xC0, 0xDC,
	0xBF, 0xBD
]

[bytebool]

UK QWERTY :

keybindings = [
   0xde, 0xc0,
   0xc0, 0xdf,
   0xdc, 0xde,
   0xe2, 0xdc
]

[damajor]

Client: Moonlight Linux Server: Sunshine Windows (service) Keyboard layout: Azerty both sides

Missing '5' and ')' keys as well all modifiers for those keys (alt/shift/altgr)

[Intronirisme]

It's reassuring to see I'm not the only one to struggle with that, unfortunately as a developer I do need '(' and ')' for obvious reason, that makes sunshine unusable to me. The issue is open since 2021, there have been release since then but the problem is still there. Do you think I should keep hope or switch back to using Geforce Experience even if is way less efficient ?

[WisdomCode]

Its unfortunately deeply embedded in the way the keyboard is grabbed. When I found the issue I was eager to fix it, but I gave up as there simply wasn't some translation layer for the keyboard anywhere. Its basically happening due to the way moonlight is grabbing the keyboard, and sunshine would probably need a translation matrix for every layout. This is likely possible and maybe there is a library for it somewhere, but I wasn't able to find one. Due to this being really not trivial, I would not bet on it being resolved soon :/

[damajor]

All my keymaps issues are gone. Not sure what fixed it, but I think I ran only updates.

[DonFlix]

I have the same issue. German keyboard. Linux sunshine Server. And windows moonlight client. Nothing helped so far. I can't input ~ and | and in addition everything else behaves as if us keyboard layout.

Is there a solution? I already tried keybinds. But didn't have any effect

[FlorianWolters]

I have the same issue. German keyboard. Linux sunshine Server. And windows moonlight client. Nothing helped so far. I can't input ~ and | and in addition everything else behaves as if us keyboard layout.

Is there a solution? I already tried keybinds. But didn't have any effect

I got the same issue here using Sunshine (but on Windows) with a Moonlight Client (Android) on a NVIDIA Shield TV Pro (2019). The "keybindings" settings in sunshine.conf does seem to have an effect, but I did not yet translated all the keys using the method as described in https://github.com/loki-47-6F-64/sunshine/issues/82#issuecomment-1203065430. Note that https://github.com/loki-47-6F-64/sunshine/issues/82#issuecomment-915510820 also did not work here.

According to the https://github.com/LizardByte/Sunshine the issue should be fixed in the latest version, see https://github.com/LizardByte/Sunshine/discussions/989.

Note that disabling the setting "Always send scancodes" fixed the layout for me, but broke other stuff, e.g. holding SHIFT to activate running in a game.

[RenaudS2]

My only solution to have my AZERTY keyboard 100% functionnal Alt+Tab is the only pb i have... Use "Alt Esc" to "Alt Tab"

Use AutoHotKey 2.0, with this script ("Convert_ENG_FRA_Sunshine.ahk") Let Sunshine.conf by default To have ">" and "<" keys, use Ctrl with...

Convert_ENG_FRA_Sunshine.ahk.txt

#Requires AutoHotkey v2.0 q::a w::z a::q ,::m z::w m::; ?::M .::? :?C*:;::{,} ^=::> ^<+=::< LAlt & Esc::AltTab RAlt & =::}