GNU bug report logs - #50364
27.2; EDT mode Xmodmap related documentation needs updating

Previous Next

Full log

View this message in rfc822 format

From: Po Lu <luangruo <at> yahoo.com>
To: Hin-Tak Leung <htl10 <at> users.sourceforge.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, ca22 <at> cam.ac.uk, 50364 <at> debbugs.gnu.org
Subject: bug#50364: 27.2; EDT mode Xmodmap related documentation needs updating
Date: Tue, 23 Aug 2022 09:01:57 +0800

Hin-Tak Leung <htl10 <at> users.sourceforge.net> writes:

> 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! 

Please keep the previous method documented.  I don't use plug-and-play
keyboards (indeed PS/2 is not even safe to hotplug), and in addition to
that, Emacs runs on ancient X servers all the way back to the original
X11R6 sample server.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.