[LightDM] On keyboard layouts

[Christian Seiler]

>> 1. All greeters I've looked at (Gtk, unmaintained Qt, KDE, Razor-QT,
>> Unity) don't seem to implement this at all... Ok, the Qt-based greeters
>> are no surprise. But for Gtk/Unity: I see some references to old bug
>> reports online if I search for this, but they reference C code, whereas
>> the Unity greeter is now written completely in Vala. (At least current
>> bzr trunk.) And ok, Vala is compiled to C, but the Vala code I looked
>> at contains nothing that I could find that contains anything resembling
>> keyboard layouts.
>>
>> Am I missing something here? Currently, it appears to me that nobody is
>> actually using that code. Nevertheless, I've seen screenshots of the
>> Unity greeter with a keyboard symbol, is that perhaps an old version?
>>
> 
> Unity Greeter uses the keyboard indicator which does the keyboard
> management, so the rest of the greeter GUI doesn't need any knowledge of
> keyboard layouts. At the time I was adding keyboard support it wasn't clear
> we would use the same indicator code as the session but in the end we did
> (as well as using gnome-settings-daemon which manages some keyboard
> settings).

Ah ok, that makes sense now.

>> 2. I get a huge list of layouts from the backend, it appears to me that
>> those are all layouts that are installed on my system. (472 entries) If
>> I want to use that for writing some kind of layout switcher for a
>> greeter, I don't see how that could be made usable in a reasonable way.
>> The only greeter outside of lightdm of which I know that it supports
>> layouts is gdm3, and that uses the current XkbLayouts X setting to
>> restrict the available layouts to those, making it much easier for a
>> system administrator to choose a sane policy of available layouts.
>>
> 
> I think it depends on how XKB is configured. In my case I only get a few
> back.

I'm curious to hear how many a 'few' are, just to see how much variance
there is. (Note that GDM3 and probably Unity restrict the layouts they
show to the X server config, which means a total of no more than 4.)

> However, in the case of GNOME (and by extension Ubuntu) they've moved to
> using gnome-settings-daemon to switch between keyboard layout / input
> method combinations. I am not sure if this will become a standard across
> desktops.

I seriously doubt that KDE will use gnome-settings-daemon any time soon. ;-)

(Same thing vice-versa. ;-))

> My thoughts on where we go from here:
> - It seems desirable that liblightdm should provide basic support for
> things that a greeter could need like keyboard support. This functionality
> will be optional if a greeter wants to use something more complex /
> appropriate.

I do think the current API is already a good start for this. I don't
think anybody is currently using it, since the Unity greeter has moved
on to something else.

My suggestion would be to then just do a modification of the API *now*
in order to make sure we don't break it:

 * On first call, remember the initial xkb configuration of the X
   server and provide a function to reset the configuration to that.
   This way, after the greeter is done, it can reset to the configured
   X defaults.
 * lightdm_get_layouts() returns a list of all the active Xkb groups.
   The sysadmin can configure up to 4 login greeter layouts via the
   XkbLayout and XkbVariant settings. (This is also honored by
   GDM3/gnome-shell from my experience.)
 * Add lightdm_get_all_layouts() to retrieve all configured layouts.
   (As lightdm_get_layouts() currently does, in case someone really
   wants to know ALL layouts.)
 * Document that short_description is usually the language but mostly
   empty.
 * Add variant field and don't combine layout and variant.
 * Emit a signal if the keyboard layout has changed (also when a user
   presses a key)
 * Then add Qt bindings that provide access to the functionality.

I've looked a bit at the xklavier (lib used in LightDM) docs and this
seems to be possible without having to resort to Xkb itself.

> - We should attempt to transparently support whatever technologies are
> being used (e.g. Wayland, IBus, etc).

WRT Wayland: I agree completely, although I have no idea about details
there.

WRT IBus: to me this seems to be mostly a matter of the greeter itself
supporting it and not much LightDM core could do about it, at least from
what I gather. But if there is something the core could do (and if that
only is starting the daemon and setting 2 env variables), then I agree,
that should be done, but also here I have to confess I have no clue when
it comes to IBus.

Regards,
Christian