Support logind's automatic multiseat feature

Bug #1190581 reported by Laércio de Sousa on 2013-06-13
40
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Light Display Manager
Medium
Unassigned
1.10
Medium
Robert Ancell
lightdm (Fedora)
Invalid
Undecided
lightdm (Ubuntu)
Medium
Unassigned
Trusty
Medium
Unassigned
Utopic
Medium
Unassigned

Bug Description

[Impact]
LightDM does not use the information provided by logind to support automatic multi-seat setups. We have backported this support from LightDM 1.12 so this functionality can be used in 14.04 LTS. It is disabled by default.

[Test Case]
1. Enable multiseat in the LightDM configuration:
 [LightDM]
 logind-load-seats=true
2. Start LightDM
Expected result:
The greeter is shown on both monitors and two sessions can be logged in.
Observed result:
Currently only one monitor / seat works.

[Regression Potential]
There is some risk of unrelated code being changed. This has been reduced by the use of regression tests, manual testing and providing this in the Ubuntu Desktop PPA.

Description of problem:
Lightdm doesn't seem to properly support systemd multiseat. The first seat is properly opened on seat0, but lightdm's other seats aren't tied to any of logind's seats

Version-Release number of selected component (if applicable):
lightdm-1.7.0-2.fc19.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Set up four seats using udev (I named mine seat-1, seat-2 and seat-3, as well as leaving the default seat0)
1. Configure lightdm to use the four seats
2. Start lightdm.service
3. Run loginctl

Actual results:
   SESSION UID USER SEAT
        10 0 root
       c14 990 lightdm seat0
       c16 990 lightdm
       c17 990 lightdm
       c18 990 lightdm

Expected results:
   SESSION UID USER SEAT
        10 0 root
       c14 990 lightdm seat0
       c16 990 lightdm seat-1
       c17 990 lightdm seat-2
       c18 990 lightdm seat-3

Additional info:
Lightdm does start correctly and does use all four seats, but, because the seats aren't registered correctly with logind, USB devices don't automatically get sent to the right seat.

tags: added: multiseat

Shouldn't this go upstream? Looks more like a feature request than a bug.

Yes, it is actually open at https://bugs.launchpad.net/lightdm/+bug/1190581. I want to use this bug to track its progress in Fedora, but forgot to add the link.

Thanks for bringing this upstream.

Robert Ancell (robert-ancell) wrote :

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

Changed in lightdm:
status: New → Triaged
importance: Undecided → Medium
Richard Hansen (rhansen) wrote :

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.

Richard Hansen (rhansen) wrote :
Download full text (5.3 KiB)

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

Read more...

Laércio de Sousa (lbssousa) wrote :

> 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

Ivan (hideaki02) wrote :

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!

Laércio de Sousa (lbssousa) wrote :

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.

Richard Hansen (rhansen) wrote :

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

Laércio de Sousa (lbssousa) wrote :

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.

Laércio de Sousa (lbssousa) wrote :

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

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

Laércio de Sousa (lbssousa) wrote :

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.

Laércio de Sousa (lbssousa) wrote :

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.

Laércio de Sousa (lbssousa) wrote :

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?

Laércio de Sousa (lbssousa) wrote :

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.

Robert Ancell (robert-ancell) wrote :

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

Laércio de Sousa (lbssousa) wrote :

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?

Robert Ancell (robert-ancell) wrote :

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

Robert Ancell (robert-ancell) wrote :

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.

Changed in lightdm:
milestone: none → 1.11.7
status: Triaged → Fix Released
Laércio de Sousa (lbssousa) wrote :

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?

Robert Ancell (robert-ancell) wrote :

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

Robert Ancell (robert-ancell) wrote :

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.

Robert Ancell (robert-ancell) wrote :

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

Changed in lightdm (Ubuntu Utopic):
status: New → Fix Released
importance: Undecided → Medium
Changed in lightdm (Ubuntu Trusty):
importance: Undecided → Medium
Launchpad Janitor (janitor) wrote :

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

Changed in lightdm (Ubuntu Trusty):
status: New → Confirmed
Changed in lightdm (Ubuntu Trusty):
status: Confirmed → Triaged

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!

description: updated

lightdm-kde-0.3.2.1-8.fc19, lightdm-gtk-1.8.5-9.fc19, lightdm-1.10.3-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/FEDORA-2014-14034/lightdm-kde-0.3.2.1-8.fc19,lightdm-gtk-1.8.5-9.fc19,lightdm-1.10.3-1.fc19

Mathew Hodson (mhodson) wrote :

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

Changed in lightdm (Ubuntu Trusty):
status: Triaged → Fix Committed
tags: added: verification-needed
Mathew Hodson (mhodson) wrote :

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!

Richard Hansen (rhansen) wrote :

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

tags: added: verification-done verification-done-trusty
removed: verification-needed
Launchpad Janitor (janitor) wrote :

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

Changed in lightdm (Ubuntu Trusty):
status: Fix Committed → Fix Released
Mathew Hodson (mhodson) on 2014-12-10
tags: removed: verification-done-trusty

This message is a notice that Fedora 19 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 19. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 19 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

This has been fixed in the version of lightdm in F20.

Changed in lightdm (Fedora):
importance: Unknown → Undecided
status: Unknown → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.