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

[Colin Guthrie]

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

>> 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).

> 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)?]

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


Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/