Linux/X11 keyboard layout autodetection (and German keyboard mapping problem)

[jedcooper]

for linux: any (./configure) options necessary to get this working? keymapper can map some, not all of them correctly, f.e. the -/ key (left of right shift) will be double mapped (gives two keys) or if not with wrong key. and btw. where can i find documentation for dosbox-x enhanced config options? and overall keyboard/linux configuration

[joncampbell123]

run dosbox.conf and type:

config -all -wc ref.conf

all will be dumped to ref.conf as your reference without overwriting dosbox.conf

[joncampbell123]

Is it possible to correct the issue if you change keys around in the mapper? This would help me understand if it is possible to add code identifying a German keyboard then modifying the default map to handle it.

[jedcooper]

In parts. I have a german keyboard and a german setup in X. https://de.wikipedia.org/wiki/Tastaturbelegung#Deutschland_und_.C3.96sterreich If I don't touch anything (no mapper, no keyb loaded in dosbox) the - on the german keyboard (that's the key left of r-shift) is recognized as - and _ (shift) in dosbox. If I want to map it to slash /, then dosbox will get it as -/. öä aren't working either, they should be ;: resp. ,. at least for de->us viceversa.. neither do brackets [] etc. But they're mappable.

Then I load keyb de in dosbox. öä for ;: aren't working again. But they're also mappable. But problem exists for the - key, this is ß and ? now.

So conclusion: The automatically recognized keys regardless to X keyboard map/setting aren't mappable in the mapper which leads to problems having two keys pressed sent to dosbox if manually mapped. Further essential ;:,. etc. aren't recognized by default in any keymap used and missing completely then.

EDIT: German keyboard setup cannot be used in dosbox-x so far. If I do a "setxkbmap us" before launching dosbox it works flawlessly so far for the defaults (keyb us, codepage 437). Also ;: (which are on öä) are recognized then.

In stock dosbox 0.74 it's working for german setup ootb. So wondering what's the fault. Option keyboardlayout=auto or de or us else in .conf file doesn't change the "double mapping" stuff. Seems to be same like loading keyb.

For the enhanced config stuff: Yeah that's a lot now, 91kB file. Enough to dig around for now, thx :-) should've figured and find that out myself. sry.

[joncampbell123]

I just remembered DOSBox-X inherited DOSBox's "use scan codes" mode that you might consider using. It maps the keys using the scan codes from the keyboard rather than with the SDLK constants provided by SDL. Could you set usescancodes=true in the [sdl] section and tell me if that helps?

[joncampbell123]

I ordered a german keyboard that just arrived today. On my linux system, plugging in the keyboard and running setxkbmap de, then starting DOSBox-X and running "keyb de" seems to generate the correct scan codes. What exactly is your X keyboard map setting?

Also, is it normal for the ^ and ' keys to generate no scan code by themselves until you press another key? Is that standard over there?

[joncampbell123]

It would probably help if, like Windows, the Linux version were to also autodetect keyboard layout on startup.

http://linux.die.net/man/3/xkbgetmap

[joncampbell123]

This issue is half resolved.

DOSBox-X now queries the X11 server for keyboard layout.

It has recognition for two keyboard layouts (though not German yet).

[rderooy]

First, to your (old) question that some key's don't generate keycodes until a second key is pressed, that is normal. Those are called "dead keys", and are there to generate accent characters (éóíèòìëöï etc). You first press the accent key (e.g. "), and then press the letter you want to use the accent with. If you don't want the accent, but the character itself, you can press something like space. They can be found on many international keyboard layouts. Including the "US International" layout.

In any case. I read README.keyboard-layout-handling and looked through various source files, and found references to DKM_DEU in include/keymap.h, src/gui/sdlmain.cpp and src/gui/sdlmain_linux.cpp. I thought I could use this as a template to perhaps add support for other European keyboards. However the code seemed incomplete, nothing more then a stub, and upon setting my host keyboard to German and starting dosbox-x this was indeed confirmed. The keyboard layout is messed up, and keyb returns that codepage 437 is loaded.

Under normal operation when I start dosbox-x SDL1 on Linux, I get;

LOG: Current X11 keyboard layout (full name) is: 'English (US, euro on 5)'
LOG: Current X11 keyboard layout (token) is: 'us'
LOG: Host keyboard layout is now us (US English)
LOG: Mapper keyboard layout is now us (US English)

And everything works fine.

Setting my host keyboard to German, I get this:

LOG: Current X11 keyboard layout (full name) is: 'German'
LOG: Current X11 keyboard layout (token) is: 'de'
LOG: Host keyboard layout is now ger (German)
LOG: Mapper keyboard layout is now ger (German)

Which seems better then using something like French.

LOG: Current X11 keyboard layout (full name) is: 'French'
LOG: Current X11 keyboard layout (token) is: 'fr'
LOG: Host keyboard layout is now us (US English)
LOG: Mapper keyboard layout is now us (US English)

But in practice it makes no difference.

[rderooy]

I did some more testing on keyboard detection on Linux, and here is what I'm seeing with the current code:

• SDL1 on pure X11 with keyboard set to German works
• SDL2 on pure X11 with keyboard set to German FAILS
• SDL1 on XWayland with keyboard set to German FAILS
• SDL2 on XWayland with keyboard set to German FAILS
• SDL2 on Wayland with keyboard set to German FAILS

SDL1

Keyboard detection fails in sdlmain_linux.cpp because XkbRF_VarDefsRec.layout always returns "us" with XWayland, regardless of what the host keyboard is set to. This is also consistent with manually running setxkbmap -query:

X11

setxkbmap -query
rules:      evdev
model:      pc105
layout:     be,de,fr,gb
variant:    ,,,
options:    lv3:ralt_switch

XWayland

$ setxkbmap -query
rules:      evdev
model:      pc105
layout:     us

SDL2

Keyboard detection fails because wminfo.subsystem always returns NULL as do wminfo.info.x11.display and wminfo.info.wl.display.