[systemd-devel] Changing how localed writes keymap for xorg

[Peter Hutterer]

On Wed, Feb 11, 2015 at 02:18:12PM +0000, Colin Guthrie wrote:
> CC'ing Peter Hutterer as "the xorg input guy" for his thoughts :)
> 
> Lennart Poettering wrote on 11/02/15 11:46:
> > On Wed, 11.02.15 10:43, Colin Guthrie (gmane at colin.guthr.ie) wrote:
> > 
> >> Hi,
> >>
> >> I've recently run into an annoying problem with the localed xorg.conf
> >> snippet.
> >>
> >> As it writes an xorg.conf.d snippet, this seems ot take priority over
> >> udev properties (xkblayout) etc. which Xorg has supported for some time.
> >>
> >> If x starts with this snippet in place and it has a layout of e.g "us",
> >> but then, later a keyboard with a udev property of xkblayout fr is
> >> plugged in (don't worry about where that property comes from, this is a
> >> supported feature of the config/udev.c in xserver), it will still get
> >> the us keymap. This sucks!
> > 
> > udev is not a place for configuration really. I mean, in a few cases
> > (like seat assignments) it is what we do, but in general: no it's not
> > the place for end-user configuration. 
> > 
> > I am pretty sure that people want to assign keymaps with udev rules,
> > are smart enough to remove the config snippet localed has written.
> 
> Yeah, I'm sure they are smart enough... until localed kicks in and
> writes it again just because the user has logged into some other DE for
> a while....

IMO, this is because you're using it the wrong way around. The decision we
made when introducing xorg.conf.d snippets ~6 years ago was that
configuration overrides any system stuff. I was never a big fan of udev
setting xkb layouts directly but it was needed for Debian at the time
(iirc) and it's been there ever since. We don't support any other option
being set in udev directly.

The correct approach to configuration like you want it is to write an
xorg.conf.d snippet. localed uses the 00 prefix for a reason, so it can be
overwritten by anything that sorts higher. you can easily emulate the static
defaults by having a udev PROGRAM rule that drops a 01-... xorg.conf.d
snippet.

> >> Also, anything plugged in to Xorg after running localectl (thus updating
> >> 00-keyboard.conf) will also get the "us" keymap (as that was what was in
> >> place at Xorg init time).
> >>
> >> Wouldn't it be better to do the following:
> >>
> >> 1. deprecate the 00-keyboard.conf xorg.conf.d file
> >> 2. Instead apply the locale settings in udev via "xkb*" properties
> > 
> > No, certainly not. The Xorg fragment is actual
> > configuration. Configuration should beat the rulesets really, which
> > carry device metadata. 
> 
> Well, I don't disagree, but it would be nice to have a way such that
> inserting a new USB keyboard after configuring the global default, that
> it *actually* takes effect. Currently, without some other layer on top
> (as in GNOME), localed does not achieve this, but the udev approach does.
> 
> To summarise: currently localed requires an Xorg restart for the
> defaults to be used which is not very "dynamic and hotpluggy" which is
> the usual systemd mantra! Using udev rules would allow this to be
> dynamically supported out of the box - but it is arguably the wrong
> place to store configuration.

It would also be inconsistent. X only reads config files on startup. You may
want to configure other things at runtime like tapping, scrolling, or even
what devices are to be ignored. All of this only takes effect on server
restart.

at which point we need to ask the question: what makes keyboards so special?
and the answer seems to be that your DE doesn't support hotplugged
keyboards, per-user keyboard settings, etc. So it feels to me, and correct
me if I'm wrong here, that you want to reshape the default handling so you
don't have to fix it in your DE (I don't actually know which one you're
using, sorry).

The defaults are just that, defaults. We have some built-in ones in the
server (you can change them at configure time), localed provides slightly
more flexible defaults, but in the end it comes down to: keyboard layout is
a very user-specific thing and not as static as defaults. The DE should
handle this correctly, on a per-user basis.

> So considering you're definitely against it, another possibility would
> be to teach the evdev driver in xorg (and anything else xkb based) to
> read e.g. /etc/xkb.conf on each hotplug event. This could be a
> "standard" file that could also be parsed by kmscon and Wayland
> compositors too (as Mantas pointed out in his reply - I don't know much
> about this) and localed could manage this file instead of an xorg snippet.
> 
> 
> Or evdev could just be taught to ask localed via dbus for the xkb
> defaults and use that to trump it's startup prefs? (or if startup prefs
> are to be considered sacred, then we'd just make localed read/write it's
> own private config file (perhaps called /etc/xkb.conf or something
> higher level) and not actually write it to xorg.conf.d at all - there
> are no startup prefs and consulting localed would primary way for this
> to work). The downside here is that localed would always have to fire up
> when xorg starts (unless, I guess, if prefs *are* sacred and are all
> provided in which case you could simply skip consulting localed and
> avoid this).

fwiw, evdev doesn't do anything with the xkb layout other than collect the
options and pass it to the server on init. if anything, the above approach
would be better implemented by merging the common bits into the server.
then again, I'm not a fan of changing all this anyway.

> Are either of these options that would work for you? Both would provide
> the "dynamic" benefits that we (Mageia) have now with the udev approach.
> If either are acceptable, I could hack on that. If not, do you have any
> other suggestions for solving this problem properly?

yes. add keyboard support to your DE :)
how do you handle tapping, scrolling, all the other user-specific
configurations right now?
 
> And speaking of that, what is the long term goal for configuring
> keyboard layout settings under libinput related stuff anyway? I presume
> it somehow inherits from xorg.conf for a libinput based xorg (I think
> this is a short term plan), but how would it work under wayland... where
> will localed write this info (or will we just ask localed directly for
> the needed info here in which case where it saves/loads this info from
> is irrelevant)?

libinput itself doesn't do keyboard layouts, it sits just below. the
compositors are what handle the layouts and they'll cook up their own
scheme. GNOME works as before because the gsettings backend remains, weston
has weston.ini read on startup. the libinput xorg driver works like evdev,
i.e. it collects the options and passes them to the server.

so yeah, you'll likely run into the same issue again when your DE updates to
a wayland compositor.

Cheers,
   Peter

> So in short, I'm all for ditching our current udev scheme, but I'd only
> like to do that when localed approach provides the same level of
> functionality.
> 
> Cheers for any suggestions!
> 
> Col