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 (gm...@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/ _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel