Created attachment 1291747 [details] Keymap file from /usr/share/X11/xkb/symbols/uneaf Description of problem: I was updating rawhide today, when X suddenly reverted to QWERTY from my custom keymapping. Fortunately, this didn't affect the custom keymapping in the consoles, and after the update had completed, and when I exited and restarted X, it picked up my custom keymapping again. Version-Release number of selected component (if applicable): xkeyboard-config-2.21-1.fc27.noarch How reproducible: It is intermittent, depending on what is updated. Steps to Reproduce: 1. Have a custom keymapping 2. Update X using dnf 3. Occasional loss of keymapping Actual results: Occasionally my custom keymap disappears and I have to change where it is located. Expected results: The custom keymap is always available. Additional info: Currently in F25, where I never have issues, and in rawhide, I just put my keymap under its name in /usr/share/X11/xkb/symbols, put its name in ~/.Xkbmap, and when I use startx to start X, it picks it up. This keymap is very different from the other US variants, like dvorak, and colemak, but it has about an 80% hit rate on home row. The main drawback is the number keys, as they are arranged very differently in order to make the keyboard convenient for coding. The best way to learn the keymap is to play nethack with the keyboard movement instead of the number pad movement.
This is the stanza that would be added to /usr/share/X11/xkb/rules/base.xml and evdev.xml for the new layout. <variant> <configItem> <name>uneaf</name> <description>English (UNEAF)</description> </configItem> </variant> This is the actual keyboard layout. // uneaf custom keyboard layout // License: public domain partial alphanumeric_keys //modifier_keys xkb_symbols "uneaf" { include "us(basic)" name[Group1]= "English (UNEAF)"; // symbols row, left side key <TLDE> { [ 9, asciitilde ] }; key <AE01> { [ 8, ampersand ] }; key <AE02> { [ 7, bracketleft ] }; key <AE03> { [ 6, bracketright ] }; key <AE04> { [ 5, dollar ] }; key <AE05> { [ 4, braceleft ] }; key <AE06> { [ 3, braceright ] }; // symbols row, right side key <AE07> { [ 0, parenleft ] }; key <AE08> { [ 1, parenright ] }; key <AE09> { [ 2, equal ] }; key <AE10> { [ asterisk, at ] }; key <AE11> { [ less, exclam ] }; key <AE12> { [ greater, asciicircum ] }; // upper row, left side key <AD01> { [ colon, numbersign ] }; key <AD02> { [ c, C ] }; key <AD03> { [ i, I ] }; key <AD04> { [ o, O ] }; key <AD05> { [ period, question ] }; // upper row, right side key <AD06> { [ apostrophe, percent ] }; key <AD07> { [ p, P ] }; key <AD08> { [ s, S ] }; key <AD09> { [ d, D ] }; key <AD10> { [ comma, quotedbl ] }; key <AD11> { [ minus, plus ] }; key <AD12> { [ semicolon, grave ] }; // home row, left side key <AC01> { [ u, U ] }; key <AC02> { [ n, N ] }; key <AC03> { [ e, E ] }; key <AC04> { [ a, A ] }; key <AC05> { [ f, F ] }; // home row, right side key <AC06> { [ g, G ] }; key <AC07> { [ r, R ] }; key <AC08> { [ t, T ] }; key <AC09> { [ l, L ] }; key <AC10> { [ h, H ] }; key <AC11> { [ slash, underscore ] }; // lower row, left side key <AB01> { [ z, Z ] }; key <AB02> { [ k, K ] }; key <AB03> { [ j, J ] }; key <AB04> { [ q, Q ] }; key <AB05> { [ x, X ] }; // lower row, left side key <AB06> { [ w, W ] }; key <AB07> { [ m, M ] }; key <AB08> { [ v, V ] }; key <AB09> { [ b, B ] }; key <AB10> { [ y, Y ] }; key <BKSL> { [ backslash, bar ] }; };
The keymapping is named uneaf for the left home row layout.
basically: we don't add custom layouts in fedora unless they're in upstream (or at least scheduled for upstream). So I'm going to have to defer you to https://www.freedesktop.org/wiki/Software/XKeyboardConfig/Development/ please file your request there and we can take it into Fedora once it's merged. A further comment though: I think for custom layouts like this it's better if the xkb stack would read a user's home directory instead of you having to install it like a system directory. Long-term that's the better solution over having a bunch of custom layouts that we then have to maintain indefinitely.
Thanks, your comment makes sense and would solve my problem nicely. It seems unlikely that they will change their modus operandi after all this time, however. Maybe wayland can implement that for its keyboard mappings? My technique has worked well enough for several years, with occasional glitches, so I can continue on as I am. The best solution would be to buy a programmable keyboard, so that the keyboard is mapped to the custom key layout, but pretends to be a QWERTY to the system. Unfortunately, they all have some sort of drawback, though. Most of them still have the left side of the keyboard sloping off to the north west instead of the north east. Talk about non-ergonomic. And those that don't are pricey to just take a chance that they will be acceptable. Someday, though.