Linux: Plover does not recognize non-Qwerty layout

[lycheese]

Describe the bug

When using bone as my software layout with xkb and my qmk keyboard with Plover and hitting the STN_HL, STN_E and STN_LR keys simultaneously Plover produces the output ufii instead of hell.

The only way I have found so far to get the expected behaviour is to specify the us layout in /etc/X11/xorg.conf.d/00-keyboard.conf and reboot.

To Reproduce

Steps to reproduce the behavior:

1. Specify the bone layout through xorg config files and reboot
2. Start Plover
3. Send steno keycodes via qmk and gemini pr
4. Produce garbled output

Expected behavior

Plover recognizes the different keyboard layout and adjusts accordingly.

Screenshots

Bone Layout:

Operating system

• OS: NixOS 21.05
• Plover Version 4.0.0.dev8

Hardware

I am using a Kyria with qmk firmware and a dedicated Plover layer:

I have not made any changes to the default machine configuration apart from selecting gemini pr:

[user202729]

Does

xdotool type hell

work correctly (type the correct content hell)?

[lycheese]

Does

xdotool type hell

work correctly (type the correct content hell)?

No, it does not. But interestingly instead of Plover's ufii it types ueii. (It is very inconsistent though. Sometimes it mixes in up arrow presses and sometimes it produces ueie.)

Edit: Some of characters get through unchanged: xdotool type tieow produces tieow…what?

xdotool translations:

[input --> output]

j --> q
d --> w
u --> e
a --> r
x --> t
p --> y
h --> u
l --> i
m --> o
w --> w
ß --> [

c --> a
t --> t
i --> i
e --> e
o --> o
b --> h
n --> j
r --> r
s --> s
g --> g
q --> q

f --> f
v --> x
ü --> c
ä --> (no-op)
ö --> b
y --> y
z --> z
, --> ;
. --> '
k --> k

Edit: I am getting more and more confused. The output above was produced by invoking xdotool via dmenu. If I use Emacs' inbuilt shell command dispatcher I get ufii from xdotool type hell like I got it from Plover.

Edit: After following this thread and executing setxkbmap -layout de -variant bone, xdotool type hell now produces 7.

Edit: Seems to be a known issue even though the way it acts here is quite odd.

[lycheese]

It seems that the bug I encountered only happens when you have multiple keyboard layouts defined in the xorg config files. When only the bone layout is defined, the fix mentioned above (executing setxkbmap -layout de -variant bone) causes Plover to output the expected characters.

[user202729]

Currently Plover does not support XKB properly (see #1164 (comment)), fixing this issue will require "a lot of work".

There are some other unofficial "output engine plugins" such as https://github.com/user202729/plover-ibus (read the disclaimer)

[lycheese]

Currently Plover does not support XKB properly (see #1164 (comment)), fixing this issue will require "a lot of work".

There are some other unofficial "output engine plugins" such as https://github.com/user202729/plover-ibus (read the disclaimer)

Ah, okay. Luckily I do not need the second layout now that I have a qmk-enabled keyboard so it is no longer a problem for me. Should I close this issue or should I keep it open and make it more precise?

[benoit-pierre]

Duplicate of #650.