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

[Peter Hutterer]

On Thu, Feb 12, 2015 at 09:27:15AM +0000, Colin Guthrie wrote:
> Hi,
> 
> [You can skip the middle hunk of this reply if you're not too interested
> in use-case; it just gives some background. There are more important
> questions towards the end tho' which I'd really appreciate feedback on!
> Thanks!]
> 
> Peter Hutterer wrote on 11/02/15 22:30:
> > 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.
> 
> Thanks for sharing the background. I quite liked the idea generally, but
> it's interesting to note both yourself and Lennart aren't big fans!
> 
> > 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.
> 
> Yeah, I'm not really complaining about the snippet existing with 00, or
> the ability to override that snippet (I specifically *don't* want to
> override that snippet with another snippet in fact - I just don't like
> the fact that udev properties (which are easier to change dynamically
> and are read on hotplug events) override this init-time static config. I
> get why it's done that way round and will not push to change it. It's
> just annoying in this use case (see below for further explanation if
> you're curious).
> 
> >>>> 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.
> 
> Fair point.
> 
> > 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).
> 
> Yeah, I kinda left that out deliberately as the use case is "a bit
> special". This is basically a pre-DE mini-wizard that kicks in in live
> mode to ask the user what their locale is, setup the language, timezone
> and keyboard and then boots into the DE of choice, whether it be GNOME,
> or KDE or something else (those two being the main ones).
> 
> In the case of GNOME, setting the keymap and such is respected (assuming
> there was no 00-keyboard.conf present when X was initialised), but
> language settings (LANG, LC_* etc.) are not, and thus we are forced to
> do a X restart there. For KDE, everything works fine, LANG, keymap etc
> is all fine, and we don't need to restart X for everything to kick in
> correctly which makes for a slightly nicer user experience.
> 
> In our case we can simply arrange for there to be no 00-keyboard.conf
> present at init, so it's not the biggest deal in the world. The keymaps
> are set manually *and* any new keyboards that happen to be plugged in
> will be fine too (settings ultimately coming via udev properties in this
> case, but quite possibly appropriate daemons in the DEs will get
> involved at this stage now anyway).
> 
> Essentially I was wanting the DE config stuff to be in addition to the
> keyboard being correct in the first place as I don't want to have to go
> around and deal with the same problem on several of the lighter-weight
> DEs which, frankly, are rubbish!
> 
> Anyway, that's the background.
> 
> Longer term, this scheme is pretty nasty anyway. When we move things
> over to the systemd user session it'll be harder to "pause" the X
> session init and we will probably (have to) totally reassess all this.
> It's pretty nasty to work with as it is, so I personally won't be sorry
> to rip it all out and just do something a lot nicer.
> 
> It would also be good to allow for DE-provided first boot type wizards
> to run should they provide their own, and only use the generic one when
> the DE is too rubbish to do this :)
> 
> > 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.
> 
> Yeah I don't disagree in principle. Like I say, I just think it would be
> nice if it did handle it somewhat generically, in a hotplug friendly way
> with it's system-wide config which allowed during-runtime changes to
> that system-wide config. But if people disagree, then so-be-it!
> 
> >> 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.
> 
> Fair enough. My suggestion would have been to collect options, if any of
> xcb_{layout,model,variant,options} were not set, then try to parse them
> from /etc/something.conf, then fall back to the compiled in defaults*,
> so not a massive change, but still probably more of a change than you'd
> like to introduce at this stage in life for xorg :)
> 
> As a slight aside, the defaults for evdev seem to be:
> 
> evdev.c:93:
> 
> static const char *evdevDefaults[] = {
>     "XkbRules",     "evdev",
>     "XkbModel",     "pc104", /* the right model for 'us' */
>     "XkbLayout",    "us",
>     NULL
> };
> 
> 
> But looking in systemd's keymap file:
> 
> [colin at jimmy systemd (master)]$ grep ^us src/locale/kbd-model-map
> us			us	pc105+inet	-		terminate:ctrl_alt_bksp
> us-acentos		us	pc105		intl		terminate:ctrl_alt_bksp
> 
> It seems that pc104 vs. pc105 is slightly inconsistent. Should we try
> and sync these up in anyway? (I don't really know the implications, but
> it would be nice if they agreed!)

good point, I'll update that in evdev. inet gets added anyway, but the
switch from pc104 to pc105 as default changed a couple of yeards ago.
doesn't have much effect, we've had some sort of configuration for about as
long on most systems, so the evdev defaults rarely matter.

and thinking about it more, I might even remove it from evdev and default to
the server one, I think this code stems from when drivers _had_ to provide
the XKB configuration. Which hasn't been the case for a number of years now.

> >> 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 :)
> 
> Yeah.... thought that would be the answer here! Sadly this didn't work
> in practice for us (I'm blaming KDE, but I'm not sure where it's getting
> it's keymapping data from - I suspect it's just inheriting what it gets
> for the first login at least).

iirc it's getting it at runtime, yes.

> > how do you handle tapping, scrolling, all the other user-specific
> > configurations right now?
> 
> Yeah, again this is generally just for live environment for now anyway,
> so these things are indeed generally handled via either a nice DE panel
> or xorg conf snippets if the DE is rubbish. Sadly I'm trying to work on
> a base-layer of support for several DEs, not just one so "adding it to
> the DE" is not really my preferred approach (I've patched far too many
> things in DEs I personally have no interest in over the years and I'm
> not really too keen to do that on-going - hence why I want something to
> work on a slightly lower level if at all possible)
>
> 
> >> 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.
> 
> [Slight aside, how does GNOME decide the default when a new user logs
> in? I guess it just inherits it from the X server currently, but if
> compositors handle keymaps under wayland, then there is no "default" to
> inherit (apologies if this is not the case, my understanding of the
> architecture there is fairly limited). That being the case, would g-s-d
> have to read some central default config or consult localed to get this
> "system default" value or would it rely on defaults in dconf schemas of
> some kind (although that seems horribly specific to GNOME)?]

not sure what it does/will do, but GNOME talking to some system config like
localed to get the initial default doesn't seem that far-fetched :)
in the end it's not much different to the current situation where we use
that to write a config file which eventually trickles down into the desktop.

Cheers,
   Peter

> > so yeah, you'll likely run into the same issue again when your DE updates to
> > a wayland compositor.
> 
> Cool, so I guess a take-away from all this is that localed should
> (sooner rather than later) start writing it's Xkb model/layout config in
> a different location that is separate from the xorg snippet (while still
> generating that snippet), so that locale settings are not lost one day
> on upgrade when xorg.conf.d snippet writing finally dies a death.
>
> 
> If that is agreed upon, what should the file be called? Should it be in
> vconsole.conf, does that name really fit? Should we just start writing a
> generic locale.conf file or is that taken already?