@Leopard1907 I have a similar issue, and I don't think it's Wine's fault.
Are you using gnome? Can you post the output of the commands setxkbmap -query and setxkbmap -print?

@salty-horse I'm on Cinnamon , afaik that is a Gnome forked DE.

setxkbmap -query rules: evdev model: pc105 layout: tr

setxkbmap -print xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+tr+inet(evdev)" }; xkb_geometry { include "pc(pc105)" }; };

So in this case if i try to type "i" for instance game sees this as " ' " character.

If i add a US keyboard layout and log into game with it selected , i can type i normally.

Turkish language has both ı and i letters. Not like US's big letter I and small letter i.

Native games are not suffering from that or i didn't came across within 3 years.

OK, that's a different issue than the one I had.

Let's see what Wine thinks about the keyboard.
Run the game in Steam and then quit. It created a file at /tmp/proton_run that you can run outside of Steam.

Edit it and change the WINEDEBUG line to WINEDEBUG="trace+keyboard,trace+key" \.

Now run the script. It will print out a lot of things. I'm specifically interested in the line that says:

X11DRV_KEYBOARD_DetectLayout detected layout is

followed by the detected layout.

Then search backwards and find the place where it analyzes the detected layout:

X11DRV_KEYBOARD_DetectLayout Attempting to match against [whatever the layout that was detected]

paste all of the text from that line until the summary that says something like

X11DRV_KEYBOARD_DetectLayout matches=0, mismatches=51, seq=0, score=-204

The lines in between should report mismatches.

Also look for the section mentioning "Turkish keyboard layout tr" (if it was not the matched keyboard).

Fwiw , i also opened a bug report on Wine tracker as well like 9 months ago. Issue still persists.

https://bugs.winehq.org/show_bug.cgi?id=46102

Still exist and no replies at all. I give up.

Closed the issue on Wine tracker also. Probably won't be fixed for a few years but there is always hope.

@aeikum

Sorry for pinging. Looks like that issue also happens with German keyboard layout too but there was literally no activity on bug report ( probably missing something that i can't provide , like patches for example)

https://bugs.winehq.org/show_bug.cgi?id=46102

Well , i reopened issue on Proton tracker but wine bug is still closed since there is nothing to add on it any further.

I think that is not an important thing for Wine itself , so is there a possibility for seeing a fix for this issue at least in Proton?

I believe these are all manifestations of this winehq bug: https://bugs.winehq.org/show_bug.cgi?id=30984

In general, if a bug isn't seeing activity, it's most likely because we just haven't had time to look into it, not because you did anything wrong. We're a pretty small team, and there's a lot of work to do.

Thanks for the reply. I'll keep an eye on this bug report then.

Most of this is fixed with wine staging patchset winex11-key_translation. this patchset is made specifically for this bug (30984 is the definition in the staging patches).

I use it in my warframe proton builds with no noticeable problems. It also does not interfere with any fullscreen hack commits or other winex11 modifications valve has made, and applies cleanly.

Can confirm that GE's version also fixed a very similar problem with a Belgian Azerty keyboard (also 2 keys that get detected wrong)

Actually, it worked 3 days ago, now I open warframe and it's back to the same problem again.
On closer inspection, it seems like the '2' key above the wasd is fixed.
But the g and h key still output ç and è respectively, instead of their normal letters
@GloriousEggroll

thibault@Quinn Linux 5.6.16-1-MANJARO x86_64 20.0.3 Lysia
~ >>> setxkbmap -query                                                                                                                                                                                                         
rules:      evdev
model:      pc105
layout:     be
options:    terminate:ctrl_alt_bksp
~ >>> setxkbmap -print                                                                                                                                                                                                         
xkb_keymap {
        xkb_keycodes  { include "evdev+aliases(azerty)" };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc+be+inet(evdev)+terminate(ctrl_alt_bksp)"    };
        xkb_geometry  { include "pc(pc105)"     };
};

Hi! I have a Brazilian ABNT keyboard and the keys won't match. Then I've tested with cuphead.

First simple notepad...
export STEAMAPPS=/path/steamapps
export WINEPREFIX=$STEAMAPPS/compatdata/268910/pfx
WINEDEBUG="+key" wine64 notepad

Then did the same with /tmp/proton-user/run:
WINEDEBUG="+key" \

In both I have the same entries:
0038:trace:key:EVENT_event_to_vkey e->keycode = 97
0038:trace:key:X11DRV_ToUnicodeEx returning 1 with L"/"
0038:trace:key:TranslateMessage 1 -> PostMessageW(0x8005e,WM_CHAR,,00560001) for in L"/"

In WINE/notepad, the character "/" is printed as expected, but in PROTON/cuphead the key is not even detected (I can't set it to a game action).

I think the key press and release code from WINE/notepad is working as expected, because it will use the converted symbol, but the conversion in Proton/cuphead is failing, because it uses the keycode directly and somehow it is not using the locale specific conversion table... It is always using US layout, but I don't know where to search.

Hope to have helped to narrow the search a bit...

Thank you!

Hi!

I did one more test, with the Brazilian "left bracket" key: 2 keys on the right of "P" key.

setxkbmap us

xev output

KeyPress event, serial 37, synthetic NO, window 0x3400001,
root 0x686, subw 0x0, time 801574, (228,-102), root:(859,272),
state 0x10, keycode 35 (keysym 0x5d, bracketright), same_screen YES,
XLookupString gives 1 bytes: (5d) "]"
XmbLookupString gives 1 bytes: (5d) "]"
XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x3400001,
root 0x686, subw 0x0, time 801678, (228,-102), root:(859,272),
state 0x10, keycode 35 (keysym 0x5d, bracketright), same_screen YES,
XLookupString gives 1 bytes: (5d) "]"
XFilterEvent returns: False

Then notepad and cuphead with +key... Everything is fine...

0024:trace:key:X11DRV_KeyEvent type 2, window 4400001, state 0x0010, keycode 35
0037:trace:key:X11DRV_KeyEvent type 2, window 4600001, state 0x0010, keycode 35

Then with br layout...

setxkbmap br

xev:

KeyPress event, serial 37, synthetic NO, window 0x3400001,
root 0x686, subw 0x0, time 841066, (251,-14), root:(882,360),
state 0x10, keycode 35 (keysym 0x5b, bracketleft), same_screen YES,
XLookupString gives 1 bytes: (5b) "["
XmbLookupString gives 1 bytes: (5b) "["
XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x3400001,
root 0x686, subw 0x0, time 841098, (251,-14), root:(882,360),
state 0x10, keycode 35 (keysym 0x5b, bracketleft), same_screen YES,
XLookupString gives 1 bytes: (5b) "["
XFilterEvent returns: False

Then first notepad and cuphead with +key... Everything is fine...

0024:trace:key:X11DRV_KeyEvent type 2, window 4400001, state 0x0010, keycode 35
0029:trace:key:X11DRV_KeyEvent type 2, window 6000001, state 0x0010, keycode 35

Edit: Now both are detecting the same keycode...

So I guess converting keycode back to symbols is missing the locale layout for some games...
Elite Dangerous is working (almost) fine...

Maybe Proton or WINE could force the locale layout before game start...

Thanks

Hi!

I've added cmd.exe, notepad.exe and regedit.exe to the folder of Cuphead.exe.
Then changed in /tmp/proton-user/run the executable to cmd.exe. The keyboard was correct...
Then executed regedit and notepad... Everything was fine...
Then executed Cuphead... It can't detect the keys...
When I exited... Fell back in the cmd.exe and everything was fine again...

So I think WINE and PROTON are fine... Various games doesn't take in consideration the locale keyboard...

Thanks!

If I may chime in...

I've had this problem for years, both in Wine and Proton. I use a Belgian azerty keyboard.
In many (all? - need to check) Windows games I play the numeric key 2 above WASD isn't recognized. Usually this isn't a big problem since I remap the key to another, but some games are hardcoded to use that key (e.g. Tron 2.0) which stops my progress dead in it's tracks. Even if I set 'setxkbmap us' before it doesn't work. However, in Notepad under Wine it works fine.

I have a similar problem, but I am not sure if this is the same bug or a different one.

How to reproduce: have two keyboard layouts (EN US and non-latin one, like RU in my case). Make the non-latin characters layout active and launch a game. Reproduceable with Barotrauma, Cities Skylines.

Actual result: the game is unresponsive to letter hotkeys.

Expected result: letter hotkeys work normally. In the worst case, If they do not work, switch layout to EN US without relaunching the game, and then they work.

Hi there! The Proton Experimental branch contains some patches that we hope will help these keyboard layouts. We need some testing from users with affected hardware. If you've been experiencing keyboard problems with non-EN-US keyboard layouts, please try the Experimental branch and let us know if it helps!

Has anyone tried the Experimental branch to see if the keyboard layout problems are fixed?

Hi @aeikum, my apologies for not aswering for so long. I was going to try it out, but then I have realized that the games I had issues with were running under Steam Play, not Proton. I do not know the relation between the two tools, but I tried to launch Barotrauma under Proton Experimental and it crashed. I scratched my head and shrugged my shoulders and moved on.

I would be away from my linux PC until mid-February, but then I would happily help you to test it if this would in the end fruit in fixing the issue in Steam Play.

@aleksei-korolev fwiw, Steam Play and Proton are synonymous :) Enabling "Steam Play" just enables you to use Proton for any game.

These changes have been included in the 6.3 branch. Still hoping someone can tell us whether the situation has improved or not :)

Hi,

Sorry for the late response. I couldn't make neither Barotrauma or Cities Skylines run with custom compitability option in the game properties, so I changed general settings (enable steam play for unsupported titles -> use proton 6.13-1). Barotrauma still crashes on load. Cities Skylines show behavior no different from November. However, Cities supports Linux natively, so it should ignore that setting anyway. I don't know how to check which proton version SteamPlay uses for native titles. If it uses latest stable proton version, then I guess that my issue is a separate bug.

UPD: yeah, right, you don't need a compitability layer software to run Linux apps on Linux. My Cities issue is not related to this project anyhow then. Maybe I'll dig through my library for some Windows games that do not work with funny keyboard layouts.

I'm currently dealing with the same / a related problem.

I am trying to run Risk Of Rain Returns with Proton 8.0 on EndeavourOS (arch 6.7.3) with i3. I am using a custom keyboard layout, manually added as a variant in xkb/symbols/us and registered in xkb/rules/evdev.xml. When using this layout, most of my in-game keys are shifted one to the left (i.e. pressing A will have the game thinking I pressed S, pressing S gets registered as D, etc.), but some are also all over the place (pressing Y is registered as U - maybe this has something todo with the fact that I have Y/Z switched compared to the normal us layout?).

However, when using the default us layout or even the default German de layout, all keys work without problems, so maybe this qualifies as a retest in that regard and is good news for everyone simply using a default layout.

For now I have resorted to simply adding a hotkey that changes my keymap on the fly to default us.

This problem appears on all games I have tested, and both Proton 8.0 and Proton Experimental. I can provide further logs if needed.