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

[Colin Guthrie]

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

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


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


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?


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


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


-- 

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/