[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#50364: 27.2; EDT mode Xmodmap related documentation needs updating
From: |
Po Lu |
Subject: |
bug#50364: 27.2; EDT mode Xmodmap related documentation needs updating |
Date: |
Tue, 23 Aug 2022 09:01:57 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) |
Hin-Tak Leung <htl10@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.