Support logind's automatic multiseat feature

LightDM should create seats as required from the information as provided by logind. It should report these using the current D-Bus API.

Before adding automatic multiseat support, I'd like to see basic manual multiseat support added. I've linked a branch to bug #1085841 that allows users to manually add seats. It performs steps 3 and 4 of <http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/>.

If/when that is merged, perhaps I can work toward adding automatic multiseat support. I'd have to get hardware first. Thanks to a comment from Jeremy Bicha, I discovered that Lennart has some hardware available for those who want to add automatic multiseat support: <https://lists.fedoraproject.org/pipermail/devel/2013-July/185145.html>. I'm not sure if I'll have the time to code up automatic multiseat support, so I don't want to ask for hardware just yet. But if anyone else out there is interested in fixing this bug then perhaps you can score some free hardware.

(discussion continued from
<https://code.launchpad.net/~a7x/lightdm/multiseat/+merge/178511>)

Laércio de Sousa (lbssousa) wrote on 2013-08-16T12:15:29Z:

> Robert Ancell (robert-ancell) wrote on 2013-08-13T05:21:32Z:
>
>> I'm not sure but we may need seat0 to start before seatN since only
>> seat0 will setup the VT. But since seatN doesn't seem to do
>> anything with the VT this may not be the case. (X may even have a
>> bug in this regard since seatN doesn't setup the VT but it does
>> reset it on exit).
>
> I think it will be clear when automatic multiseat support
> arrives. In that scenario, seat0 will be always available (static
> seat), while the other seats must be started on
> org.freedesktop.login1.Manager.SeatNew() triggers (on demand/dynamic
> seats). So it's natural for me that seat0 must start first.

IIUC, this is what logind wants display managers to do:

  1. Connect to the following signals to react to seat events:
     * org.freedesktop.DBus.Properties.PropertiesChanged() for changes
       in org.freedesktop.login1.Seat object properties (for when
       CanGraphical changes)
     * org.freedesktop.login1.Manager.SeatNew()
     * org.freedesktop.login1.Manager.SeatRemoved()

  2. Use org.freedesktop.login1.Manager.ListSeats() to spawn greeters
     on CanGraphical seats that were created before the signals were
     connected

(the above is derived from
<http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/>)

I didn't see any documentation guaranteeing that seat0 is reported
first. I suspect that logind creates seat0 before any other seat, so
if the signals are connected before any seats are created, LightDM
should hear about seat0 first. If LightDM starts up after seats have
been created, I would expect seat0 to be the first seat returned by
ListSeats(). Thus, I believe that LightDM can easily do the seat0 VT
switching before starting any other seat.

However, I don't see why seat0 must be a CanGraphical seat. If seat0
doesn't have to be a CanGraphical seat, then LightDM won't know
whether a non-CanGraphical seat0 will eventually become a CanGraphical
seat or will stay a non-CanGraphical seat. Waiting to start the other
seats until after seat0 is started might mean that LightDM could wait
forever.

So unless seat0 is guaranteed to be a CanGraphical seat at some point
during the boot process, LightDM can't afford to impose any
requirements on seat0 startup order. It needs to be able to cope with
seat1 starting before seat0 starts (if seat0 ever starts a greeter).

Right now the only dependency between seats is the VT the seats are
running on: if multiple seats require VT services, then VT switching
must be carefully orchestrated, which means imposing a startup order.
Allowing LightDM to start seats in any order means breaking this
dependency, which means that at most one seat is allowed do stuff with
VTs.

Thus, it must be possible to invoke X in a way that prevents it from
touching VTs:
  * don't probe to see what the current VT is
  * don't attempt to switch VTs when Ctrl-Alt-F? is pressed
  * don't reset the VT on exit
  * don't let a VT see the seat's input (keyboard, mouse) events
  * etc....

> I didn't see any documentation guaranteeing that seat0 is reported
> first. I suspect that logind creates seat0 before any other seat, so
> if the signals are connected before any seats are created, LightDM
> should hear about seat0 first. If LightDM starts up after seats have
> been created, I would expect seat0 to be the first seat returned by
> ListSeats(). Thus, I believe that LightDM can easily do the seat0 VT
> switching before starting any other seat.
> However, I don't see why seat0 must be a CanGraphical seat. If seat0
> doesn't have to be a CanGraphical seat, then LightDM won't know
> whether a non-CanGraphical seat0 will eventually become a CanGraphical
> seat or will stay a non-CanGraphical seat. Waiting to start the other
> seats until after seat0 is started might mean that LightDM could wait
> forever.
>
> So unless seat0 is guaranteed to be a CanGraphical seat at some point
> during the boot process, LightDM can't afford to impose any
> requirements on seat0 startup order. It needs to be able to cope with
> seat1 starting before seat0 starts (if seat0 ever starts a greeter).

We should ask Lennart Poettering about this. It can be done via systemd-devel mailing list or via systemd Google+ community.

> I'm not sure if X supports more than one -config argument, but if not
> then users can't provide their own config file on non-seat0 seats
> using this wrapper. That could be a problem.

No. X.Org can handle only one -config argument. I wrote a patch for systemd-multi-seat-x sometime ago (it's available at https://bugzilla.redhat.com/show_bug.cgi?id=962907), that allows me to append my custom xorg.conf to /run/systemd/multi-session-x/<seatname>.

A workaround for this limitation with systemd-multi-seat-x is putting your custom config files in /etc/X11/xorg.conf.d folder, with an explicit "ServerLayout" section that should be passed to X via -layout option. In order to avoid conflicts with other graphics devices that requires no custom xorg.conf (e.g. Intel onboard chip), one needs also to provide a default config like this:

Section "Device"
    Identifier "Default Device"
EndSection

Section "Screen"
    Identifier "Default Screen"
    Device "Default Device"
EndSection

Section "ServerLayout"
    Identifier "Default Layout"
    Screen "Default Screen"
EndSection

For anyone interested in helping develop this feature, you can apply to get some free multi-seat terminals from the company that I work for. The link for the form is here: http://plugable.com/projects/plugable-open-source-hardware-samples-program

Here are out two mutli-seat terminal models: http://plugable.com/products/DC-125, http://plugable.com/products/ud-160-m

Just drop us a line and we'll get some free units out to you. No string attached, we'd just love to see better support for Mutli-seat on Ubuntu!

Hey guys! Take a look:

https://bugs.freedesktop.org/show_bug.cgi?id=69477
https://bugs.freedesktop.org/show_bug.cgi?id=69478

With these patches, I can get rid of systemd-multi-seat-x wrapper. Tested on openSUSE 12.3 with KDE 4.11 and patched KDM for automatic multiseat support.

Excellent! Mind cooking up some patched packages and uploading them to the multiseat PPA?

Oh, sure! I reviewed one of the patches today according to Peter Hutterer's advice. I'll try to package them to multiseat PPA tomorrow.

Just opened a bug report here in Launchpad for easy tracking:

https://bugs.launchpad.net/xorg-server/+bug/1228095

I've upload my xorg-server saucy package with additional patches to my personal multiseat PPA (ppa:lbssousa/multiseat). It includes:

- Fix 'no devices detected' error for non-seat0 seats.
- Enable default settings for non-seat0 seats (no need of systemd-multi-seat-x wrapper/additional command line args)
- Add MatchSeat capability in xorg.conf

You may want to test if before I copy it to ppa:ubuntu-multiseat/ppa.

Hi guys!

I'm pleased to annouce that my second xorg-server patch is now upstreamed:

xfree86: Keep a non-seat0 X server from touching VTs (#71258)
http://cgit.freedesktop.org/xorg/xserver/commit/?id=46cf2a60934076bf568062eb83121ce90b6ff596

With this patch, non-seat0 X servers no longer require VT allocation. So, when this patch arrives to ubuntu xorg-server packages, there will be no need to allocate VTs for non-seat0 X servers in LightDM.

I've started writing some code to implement automatic multiseat support in LightDM [1], largely based on GDM implementation of the feature. After several tries, I've got this state, which is a little bit well written, but still incomplete.

I'll really like your feedback about this branch. At the moment, I can list the following issues:

* Some login1-related code was introduced, and login1.h was #included, in lightdm.c itself. Is this OK? Should this code be moved elsewhere?

* We need to implement properly the functions add_login1_seat() and remove_login1_seat() declared in lightdm.c.

* When loading initial seat list from logind (by calling login1_sync_seats()), we always get at least seat0, which may conflict with LightDM property "start-default-seat", so we may end up with two seat0 seats registered in LightDM (one triggered by start-default-seat, and another triggered by login1_sync_seats()). Which is the preferred way to prevent this conflict?

* Currently, callback functions for logind signals SeatNew() and SeatRemoved() should be implemented outside login1.c. Do you agree?

[1] https://code.launchpad.net/~ubuntu-multiseat/lightdm/automatic-multiseat

Well, since revision 2038, we can consider this bug practically fixed. LightDM now adds/removes seats dynamically following logind SeatNew()/SeatRemoved() signals, and also listens on logind seats' CanGraphical property changes.

However, I think there's a last case that should be tested --- and it could be the most critical, although least probable, one: systemd boots too fast that lightdm service is started before main graphics device is loaded. In this case, seat0 would start as CanGraphical=no, and then switch to CanGraphical=yes after graphics device is ready.

I'm not sure if lightdm at revision 2038 can handle this case.

Agreed, we should test this case and fix it if not.

Robert, I've not tested it yet, but I've noticed that lightdm currently sets exit-on-failure for seat0 by default, which would make it exit prematurely in that critical case.

Maybe we only need to wait until seat0 property CanGraphical changes to true once before enabling exit-on-failure for this seat. What do you think?

LightDM doesn't create a Seat object until CanGraphical is true so I don't think there's a problem there.

I'm going to close this bug because we now meet the bugs title "Support logind's automatic multiseat feature". Please open new bugs for errors or new features.

Robert, automatic multiseat support is a great missing feature for a LTS release like 14.04. Could we backport 1.11.7 patches (without CanGraphical check) for 1.10 series?

I'm not opposed to backporting, though we have to make it disabled by default so we don't break backwards compatibility. We should add two config options:

[LightDM]
automatic-multiseat=false
multi-seat-check-graphical=false

Oh, looking at the GDM code it appears they don't check if seat0 has CanGraphical set to True which is why we're probably seeing new problems there.

I did a first cut at backporting in lp:~robert-ancell/lightdm/automatic-multi-seat-1.10

Status changed to 'Confirmed' because the bug affects multiple users.

Thanks for uploading the fix for this bug report to -proposed. However, when reviewing the package in -proposed and the details of this bug report I noticed that the bug description is missing information required for the SRU process. You can find full details at http://wiki.ubuntu.com/StableReleaseUpdates#Procedure but essentially this bug is missing some of the following: a statement of impact, a test case and details regarding the regression potential. Thanks in advance!

https://launchpad.net/ubuntu/+source/lightdm/1.10.3-0ubuntu2 is available in trusty-proposed.

---------------
lightdm (1.10.3-0ubuntu2) trusty; urgency=medium

  * Refresh patches

 -- Robert Ancell <email address hidden> Fri, 10 Oct 2014 21:24:51 +1300

lightdm (1.10.3-0ubuntu1) trusty; urgency=medium

  * New upstream release:
    - Fix crash when having configuration keys defined in multiple places
      (LP: #1377373)
    - Allow user switching in multi-seat until bug stopping greeter showing on
      logout is fixed
    - Don't access .dmrc files until information from these files is required
      (LP: #1370852)
    - Do timed autologin each time you are returned to the greeter
      (LP: #1302491)

 -- Robert Ancell <email address hidden> Thu, 09 Oct 2014 09:01:21 +1300

lightdm (1.10.2-0ubuntu1) trusty; urgency=medium

  * New upstream release:
    - Use logind to provide the list of seats to use. This is disabled unless
      logind-load-seats (in [LightDM] section) is set to true. This is the
      default behaviour in lightdm 1.12. (LP: #1190581)
    - Fix crash if running script hooks with non-X display servers.
      (LP: #1305006)
    - Add a seat option 'allow-user-switching' that can disable all user
      switching for that seat. (LP: #1350357)
    - Make PAM services configurable. (LP: #1348251)
    - Add liblightdm method to get user UID. (LP: #1370327)
    - Add a new session type 'mir-container' that allows the session to run
      inside a custom system compositor. (LP: #1359332)
    - Add --show-config option that shows combined configuration.
    - Use XDG_SESSION_ID from PAM instead of using the logind D-Bus API.
      (LP: #1364725)
    - Make socket writing code used between greeter and daemon more robust to
      errors.
    - Correct section name in default users.conf file.
    - Fix tests failing with Qt 5.3 due to it checking getuid/geteuid which we
      are faking.
    - Fix small memory leaks.
    - Test improvements

 -- Robert Ancell <email address hidden> Wed, 17 Sep 2014 16:27:53 +1200

lightdm is available in the trusty-proposed repository and at https://launchpad.net/ubuntu/+source/lightdm/1.10.3-0ubuntu2 .

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

The trusty-proposed package works for me; no observed regressions.

This bug was fixed in the package lightdm - 1.10.3-0ubuntu2

---------------
lightdm (1.10.3-0ubuntu2) trusty; urgency=medium

  * Refresh patches
 -- Robert Ancell <email address hidden> Fri, 10 Oct 2014 21:24:51 +1300