Add basic systemd-logind multiseat support

Just found https://bugs.launchpad.net/lightdm/+bug/930488. Sorry for the duplicate.

I don't think this is a duplicate of bug #930488. That bug was about adding basic logind support, and I view this bug as a request to take it further and add basic multiseat support.

For LightDM to completely support multiseat, it should follow the protocol outlined here:
http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/

Just performing steps 3 and 4 under "complete porting" would get us 90% of the way there. Automatically discovering and reacting to seats appearing and disappearing (steps 1 and 2) would be nice, but that's a fancy feature that can come later (see bug #1190581).

I have uploaded the package in the linked bazaar branch to my PPA (<https://launchpad.net/~a7x/+archive/multiseat>) along with some backported saucy packages for improved logind support in raring. To install:

    sudo apt-add-repository ppa:a7x/multiseat
    sudo apt-get update
    sudo apt-get upgrade

I assume you guys already have multiseat hardware, but if not, Lennart was offering some to those who want to improve multiseat support.

https://lists.fedoraproject.org/pipermail/devel/2013-July/185145.html

As multiseat support in LightDM is enhanced, please consider the following:

1. There are currently two models of multiseat setup: one based on USB multiseat devices with DisplayLink (or similar) technology, like Plugable Docking Station, and another one based on multiple video cards, with keyboards/mice/audio devices plugged directly in the CPU or via ordinary USB hubs.

In the first model, input assignment to each seat is trivial: one only needs to pair the display and input connected to the same multiseat device, which is done automatically. On the other hand, the second model (most common in Brazil), display and input pairing is not trivial. The common solution, found in proprietary solutions like Userful Multiseat and Windows Multipoint Server, to do the right seat assignment for input devices is an interface of kind

"Please press F<x> key in the keyboard in front of this display",

where <x> is 1 for the first seat, 2 for the second seat, etc. If the keyboard is connected to a hub, all other devices connected to the same hub are automatically assigned to that seat. It would be nice if LightDM could implement such an interface for seat assignment.

2. Before systemd-logind, all multiseat settings were DISPLAY-oriented, but now IMHO it makes more sense to write these settings in a more "seat id"-oriented fashion. In lightdm.conf, instead of having

[Seat:1]
(...)
xserver-seat=seat-1
(...)

I propose something like

[seat-1]
(...)
xserver-display=:1
(...)

This approach is specially useful for autologin. It make more sense to assign autologin users to seat ids than DISPLAY values. I want, for example, user "bob" loggind automatically in seat-1, regardless of which is the value of DISPLAY environment variable on that seat.

> 1. [...] The common solution, found in proprietary solutions like
> Userful Multiseat and Windows Multipoint Server, to do the right
> seat assignment for input devices is an interface of kind
>
> "Please press F<x> key in the keyboard in front of this display",
>
> where <x> is 1 for the first seat, 2 for the second seat, etc. If
> the keyboard is connected to a hub, all other devices connected to
> the same hub are automatically assigned to that seat. It would be
> nice if LightDM could implement such an interface for seat
> assignment.

That is way down the road, and should be the topic of another bug
report. This bug report should only be about adding *basic* multiseat
support. We must learn how to walk before we can run.

>
> 2. Before systemd-logind, all multiseat settings were DISPLAY-oriented,

That is incorrect; the ":0" in [Seat:0] has nothing to do with the
DISPLAY. The part after the colon is an arbitrary string. You can
use [Seat:Bob] if you want to; it makes no difference (other than for
logging, and only if you install the version of LightDM from my PPA
which has some logging improvements).

> but now IMHO it makes more sense to write these settings in a more
> "seat id"-oriented fashion. In lightdm.conf, instead of having
>
> [Seat:1]
> (...)
> xserver-seat=seat-1
> (...)
>
> I propose something like
>
> [seat-1]
> (...)
> xserver-display=:1
> (...)

Due to user switching, it does not make sense to have an
'xserver-display' setting for a seat -- a single LightDM seat might be
associated with multiple X displays.

> This approach is specially useful for autologin. It make more sense
> to assign autologin users to seat ids than DISPLAY values. I want,
> for example, user "bob" loggind automatically in seat-1, regardless
> of which is the value of DISPLAY environment variable on that seat.

That is currently possible with the version of LightDM in my PPA:

    [Seat:foo]
    xserver-seat=seat-1
    autologin-user=bob

Note that it is important to keep the LightDM seat name and the X seat
name independent because LightDM isn't just for launching X.

> That is way down the road, and should be the topic of another bug
> report. This bug report should only be about adding *basic* multiseat
> support. We must learn how to walk before we can run.

Bug reported: https://bugs.launchpad.net/lightdm/+bug/1204067

> That is incorrect; the ":0" in [Seat:0] has nothing to do with the
> DISPLAY. The part after the colon is an arbitrary string. You can
> use [Seat:Bob] if you want to; it makes no difference (other than for
>logging, and only if you install the version of LightDM from my PPA
> which has some logging improvements).
> (...)
> That is currently possible with the version of LightDM in my PPA:
>
> [Seat:foo]
> xserver-seat=seat-1
> autologin-user=bob

OK. Thank you for explanation. The important thing here is making autologin user setting independent of DISPLAY value, as LightDM already does, right?

This should be there now, please open new bugs if any features are missing.