Subject: bug#50364: 27.2; EDT mode Xmodmap related documentation needs updating

From: Hin-Tak Leung <[email-masked]>
Date: Sat, 4 Sep 2021 20:51:37 +0000 (UTC)

On Saturday, 4 September 2021, 07:19:39 BST, Eli Zaretskii <[email-masked]> wrote:

> Thanks.  Would you like to write some text that explains how to
> achieve this on modern platforms?  We could then update or augment
> what the manual says as appropriate.

Yes, I could do that, when I figure out a neat way of doing it.

The current EDT documentation is misleading/out-dated in two aspects:
it gives the impression that ~/.Xmodmap is auto-applied when a user logs in
to an X session. This file is ignored for about a decade for Gnome now,
and likely KDE, too. The second matter is that even if a user manually
runs "xmodmap ~/.Xmodmap", gnome-setting-daemon (and its KDE
equivalent, kxkb) periodically resets any manually applied xmodmap keyboard
mappings.

As far as I understand it, this is driven by two modern linux usages: plug-and-play
keyboards and power management, and desktop-wide international input support.
Thus keyboard layouts are re-applied, whenever user plugs in new external
keyboards (for laptops), screensaver/monitor sleeps, or keyboard goes to sleep
and wake up. Keyboard layouts are also reset when a user explicitly choose
to input non-ascii characters via switching the desktop input methods.

Since modern Xorg can auto-detect unusual keyboards and already bundles
190 models and 100 layouts (on my system), it seems to be quite difficult to
"only" remaps a few keys.

The smallest change that is persistent is doing both: 

Editing /usr/share/X11/xkb/symbols/pc, from
23: key <NMLK> { [ Num_Lock ] };
to
23: key <NMLK> { [ Clear ] };

and append to "gsettings get org.gnome.desktop.input-sources xkb-options" (retrieving the current xkb options)
with 'numpad:mac' using "gsettings set org.gnome.desktop.input-sources xkb-options" (setting it).

The combination of these two effectively turns the numerical keypad of the PC keyboard
to closer to how the "Apple Aluminium (*)" family of keyboards behave.

This approach suffers from editing a system file (and requires admin privilege, and
also needs redoing on package upgrades).

There are a few alternative approaches, such as declaring new keyboard layouts
(scattering a few new files across /usr/share/X11/xkb/ and editing a few existing
ones, also require admin privilege) or custom scripts trigged to run on power/plug
events (details of this functionality seems to have changed over the years, and
flaky). So I haven't found a satisfactory answer that is simple, persistent,
user-config-only without root privilege, applicable to different Linux vintage, yet.

I can condense and improve the above into a patch, if you are happy to take it...

Argh, there is also advice about running a script in the background which
periodically runs "xmodmap ~/.Xmodmap" every 5 or 10 seconds!