Xmodmap reset on keyboard reconnect (issue)

[Abraham S.A.H.]

Hey @Tyler;

For the purpose of Emacs, and in general, I can suggest using ‘keyd’
or similar programs that act on input device events and scan-codes
before them being received by display server.  It let your
configuration to work in both X and Wayland and most importantly in
Linux Console.  It stays safe from X or Wayland display server
crashes, and is not overridden by input methods.  They are usually
easier to configure, too.

As with XKB, I never tried to remap modifiers through XKB.   So I really
don't know how to map menu/app to hyper by modifying XKB configuration.

However, XKB already has a few predefined options that maps different keys to 
hyper.  One of them is `ctrl:hyper_capscontrol` which maps caps-lock as Ctrl and 
Ctrl as Hyper.

If you wanted to go with xkb-extension, here is a copy of what I have written to
one of my friends before:

What is currently known and used as keyboard ‘layout’ is provided
through XKB extension, both in X11, and through ‘xkbcommon’ library,
in Wayland.  It supports up to four layouts (groups), each with up to
four ‘levels’.  It’s in difference with the core traditional
X keyboard model—X older keyboard mechanism only supported two layouts
(groups), with each of them having only two modifier states (better
say ‘shift’ states) or levels.

Almost, all of recent versions of current Desktop Environments and
most of X applications use XKB for keyboard input.  Yet, XKB provides
the compatibility that is necessary to work with applications
following pre-XKB keyboard protocols.

(Please, someone correct me if I’m wrong.)

The CLI commands to work with XKB extension are basically ‘setxkbmap’
and ‘xkbcomp’.  Also, the ‘xkbcli’ command from ‘libxkbcommon’ can
be used.  They three are documented in their respective manpages.

‘xkbcli interactive-x11’ can be used to interactively debug XKB
keymaps; it meant to be used instead of ‘xev’ for XKB purposes;

The easier approach is usually about getting your current keyboard
composition, using ‘xkbcomp :0 -o keymap.xkb’, modifying it and
feeding it back to the server, using ‘xkbcomp keymap.xkb :0’.
That being said, I’m not sure if it survives the problems that
‘xmodmap’ could not.

The other approach is to write a ‘symbol’ by including another symbol
as the fallback and overriding what you would like to be different or
added.  When ‘evdev’ as the rules component you don’t need to
introduce your added layout, you just need to put your symbol’s
configuration file in ‘/usr/share/X11/xkb/symbols’ directory.

For example:

~~~
default partial alphanumeric_keys
xkb_symbols "basic" {
include "us(basic)"
name[Group1]= "New (US)";

key <AE01> { [ exclam,          1]     };
key <AE02> { [ at,              2]     };
key <AE03> { [ numbersign,      3]     };
key <AE04> { [ dollar,          4]     };
key <AE05> { [ percent,         5]     };
key <AE06> { [ asciicircum,     6]     };
key <AE07> { [ ampersand,       7]     };
key <AE08> { [ asterisk,        8]     };
key <AE09> { [ parenleft,       9]     };
key <AE10> { [ parenright,      0]     };
};
~~~

Which simply uses the ‘us’ default basic layout but swaps the top row
so numbers are on shift.

However, that usually needs some understanding and familiarity with
how XKB works.  Since documentation around it is either scattered or
too technical, I give you some hints here.  You still need to read
a more detailed documentation about the syntax of configuration files.

As a short summary, a ‘Keymap’ in XKB, is compiled from six
‘components’.  They are together called ‘KcCGST’.  Each component is
defined in its own ‘section’ in XKB configuration files:

The default location of their configuration files is usually
‘/usr/share/X11/xkb’.  Configuration files of each component is
gathered in its own subdirectory.

- ‘Kc’ for Keycode: This component, among other things, assign
  symbolic names or labels to keycode numbers.  So that, you can use
  ‘AD01’ instead of keycode ‘24’ for ‘q’ button of your keyboard.
  Therefore, from definition of this component on, you have a keycode
  NUMBER vs. keycode NAME which both point to the same physical key,
  but the latter is easier to referr to and doesn’t require you to
  search for the keycode number produced by a key button.
  These keycode aliases have either a common traditional meaning, like
  ‘<SPCE>’ for ‘space’, or express some relative location on
  a keyboard, like ‘AB01’ for the first column (01) of the second row
  (B) which has ‘Z’ label in a US keyboard; in XKB style, other
  components use keycode labels instead of keycode numeric codes.

- ‘c’ for compatibility: This component defines actions that happen on
  key combination, and internal behaviour of modifiers; It’s called
  compat since it provides the compatibility required by (rare) apps
  that try to use older core X keyboard protocol directly and don’t
  use XKB report of keyboard events and state.

- ‘g’ for geometry: “describes the physical location and dimensions of
  each key.  It has no other purpose than allowing clients to display
  how the keyboard looks.”  It’s chosen automatically, otherwise
  manually by user through ‘Model’ higher level component I describe
  later;

- ‘s’ for symbols, which I describe it in a moment;

- ‘t’ for types: “defines the various types of keys and their
  behaviour when modifiers are pressed.”  Each key has a type that We
  assign a ‘symbols’ section.  Then, in a ‘type’ section, we define
  how the keys related to a ‘key type’ should behave when combined
  with a modifier (ctrl, shifts, caps-lock, AltGr, etc…).  (The modifier
  combinations simply refers to a key’s specific level.)  There are
  numerous predefined types which usually satisfy most needs.

The ‘Symbols’ component is the one which actually says what a key
does.  It maps keycode names (not numbers) to their symbols (‘keysyms’
as produced by ‘xev’). For instance:

There’s also a higher level ‘RMLVO’ which stands for Rules, Model,
Layout(s), Variant(s), and Options.  These are predefined,
user-friendly, mappings to KcCGST so that users don’t need to struggle
with those directly, and just specify their desired keyboard
configuration through RMLVO.

They are also reside in their respective sub-directories along with
KccGST directories.

- ‘Rules’ is ‘evdev’ most of the time, unless you are in a BSD OS
  (then it would be ‘base’); it’s the collection of rules governing
  over how following other parameters are interpreted for keyboard
  mapping composition; it’s best to not specify it so that the default
  is automatically selected by X server;

- ‘Model’ is effectively ignored at the moment, and is usually pc104
  or pc105.  They are simply not needed anymore;

- ‘Layout’ is the keyboard layout(s) you are going to use, by
  switching between them (usually, using ‘Alt+Shift’ or
  ‘Super+Space’); e.g., ‘us,fr’ for US English and French;

- ‘Variant’; some layouts have different variants to choose from.
  You can specify one for each layout in here.  It’s ignored if the
  layout(s) doesn’t have any variant.  It can be empty which the
  default (‘basic’) variant is chosen for the (or each) layout(s);
  e.g., ‘altgr-intl,’ for ‘us,fr’ (notice the extra comma after it)
  which chooses ‘altgr-intl’ of ‘us’ and the basic variant of ‘fr’
  layout;

- ‘Options’ is a, possibly empty, list of items.  Each item (an
  option) is a predefined configuration to change the keymap so that
  a user can have the desired effect; examples are:

  - ‘terminate:ctrl_alt_bks’ which binds ‘Ctrl+Alt+Backspace’ to
termination of current display server which is mostly a default.

  - Or ‘lv3:ralt_switch_multikey’ to bind ‘right Alt’ of the keyboard
to ‘ISO_LEVEL3_SHIFT’ usually known as ‘AltGr’ which can be used
in many variant of US keyboard layouts to produce a third group of
characters from pressing keyboard buttons.

A considerable number of options are provided in XKB directory
(‘/usr/share/X11/xkb’) which resolves most of the common needs.
One has to take a look at those before starting to directly modify and
make his own keyboard configuration.

List of all available RMLVO components is provided in
‘xkeyboard-config(7)’ manpage to choose from.  You usually should only
select between layouts, their variants (if necessary), extra options
to change some key bindings of your keyboard, and possibly a keyboard
model—last one mostly for aesthetic purposes.

To get the list of available RMLVO components, you may also use
‘xkbcli list’ command.


That’s pretty much what you needed to know, for the syntax of
configuration files, you could read the following article
"https://www.charvolant.org/doug/xkb/html/node5.html".

Good luck

--
Best Regards,
Abraham
Sent with Tutanota; https://tuta.com