openstenoproject
Uinput output for other layouts than US
Describe the bug
Using the modified qwerty layout from #1721 will not work with non-US layouts, as many symbols such as "-", "/", "?" etc. will not be at the same locations. For example, in norwegian the / is at shift+7 rather than at a dedicated key as in US.
The reason i did not include any special characters at all in #1679, was because it should be possible to use any layout. I suggest having separate layout options for generic (minimal) qwerty, and another for US qwerty. I also think the characters should be not in BASE_LAYOUT but in specifically qwerty-us, as BASE_LAYOUT should be the keys which are the same regardless of layout.
Relevant commit: https://github.com/openstenoproject/plover/pull/1679/files/18aaf5174a0feaa5b4e3fea2fbce72bcc1d9f561..5279766d11ad6405eb08e168a01c438f25d103de
If we would want to have all possible keyboards emulated with direct keys, we would have to implement something similar to the code that was removed, but the xkbcommon dependency caused some problems as it requires a system-wide dependency and i experienced version conflicts.
Also, i saw some confusion about this line: https://github.com/openstenoproject/plover/pull/1721/files#diff-6b4281e6a4006cf3e22f4cfbcaf9fcc8ff7337cf721c33d5051f1e6cbd369844R279
The reason it was done like that, is because that is used by the keyboard capture, which does not care about what the actual layout is, but which keys were pressed.
To Reproduce
Steps to reproduce the behavior:
- Use another layout than US (for example norwegian)
- Type some of the characters added in #1721
Expected behavior
The correct character is output
Operating system
Linux / Wayland on latest main branch
CC @user202729 @mkrnr
Thanks a lot for raising this, makes a lot of sense to me!
Regarding xkbcommon causing problems: it might be worth giving it another shot after #1720 is merged. Implementing the mapping for all the different keyboard layouts sounds painful.
I thought the library is used to magically determine the current layout in use. If it's just for pre-generate the mapping can't it be hardcoded?
I thought the library is used to magically determine the current layout in use. If it's just for pre-generate the mapping can't it be hardcoded?
Do you mean to generate the full mapping first and save it to a file? That would be possible, but i’m not sure if such a big file of keyboard layouts should be included in plover.
Isn't it included in the source code of the X server anyway?
I think making the source code more clunky for the user's convenience is worth it. Besides main.json is plenty heavy anyway.
Speaking of which is there a way to figure out the current keyboard layout automatically? This seems to be something that can be automated. If not it would be better to make the output explicitly not work until the user configures it.
Isn't it included in the source code of the X server anyway?
The point of the uinput output is to have no dependency on X11, so it wouldn't help.
I think making the source code more clunky for the user's convenience is worth it. Besides main.json is plenty heavy anyway.
Speaking of which is there a way to figure out the current keyboard layout automatically? This seems to be something that can be automated.
I don't think so, it doesn't look like there is any standards between wayland compositors. For the plugin which the upstream functionality is based on (here), i had to make the user input the keyboard layout manually and default to us with qwerty as that is likely the most used one.
Xkb also has many other things, where you don't just have layouts but also many other factors as described here.
What i think we could do, would be to generate a table of all possible languages and their corresponding layouts. (manpage)
so for example all of these:
- no
- no(nodeadkeys)
- no(winkeys)
- no(mac)
- no(mac_nodeadkeys)
- no(colemak)
- no(colemak_dh)
- no(colemak_dh_wide)
- no(dvorak)
- no(smi)
- no(smi_nodeadkeys)
As for the version conflicts i mentioned, upgrading python as mentioned would likely make it easier, but it was mostly between python and the libxkbcommon package that had to be installed system-wide that had conflicts, and that the code seemed to break on newer versions of the python package.
@LilleAila PR #1720 is merged now so this might be good time to try integrating xkbcommon again?
The Wayland protocol provides all clients a XKB keymap (https://wayland-book.com/seat/keyboard.html#key-maps) In my testing of KDE, this correctly returns the primary keymap. However, KDE doesn't send alternate layouts or layout switch events if there's multiple layouts, only returning the keymap of one of the layouts. Still, this is better than the current situation.
The two Python libraries I found to speak the Wayland protocol (pywayland and python-wayland) are work in progress.
Perhaps Plover can instead call a simple custom C module that uses libwayland to get the keymap.
