As the title says , titles using Proton are not recognizing keyboard layout correctly.
For example : It says press V to access binocular but V key is not responding.
That was also an issue with Wine as well.
Sad to see it is not any better on Proton.
Hello @Leopard1907, this should be directed at the upstream wine bug tracker.
@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.
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,
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.
Most helpful comment
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.