GNU bug report logs -
#50364
27.2; EDT mode Xmodmap related documentation needs updating
Previous Next
Full log
Message #11 received at 50364 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Saturday, 4 September 2021, 07:19:39 BST, Eli Zaretskii <eliz <at> gnu.org> 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!
[Message part 2 (text/html, inline)]
This bug report was last modified 2 years and 273 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.