Spec: Basic Multiseat Support for LightDM

Add basic multiseat support to LightDM. "Basic" includes everything listed in the freedesktop.org "Writing Display Managers" page except steps 1 and 2 under "complete porting".

Note that this spec is not about adding automatic multiseat support (steps 1 and 2 under "complete porting").

Contact: ubuntu-multiseat team

On Launchpad: blueprint


ConsoleKit was intended to help manage multiseat setups, but full support for multiseat was never integrated into any of the popular display managers.

ConsoleKit is no longer maintained and is being replaced with systemd's logind. Ubuntu started the process of migrating to logind in Ubuntu 13.04 raring (see the blueprint and associated bug report), and it will be completed in 13.10 saucy.

logind has much more robust support for multiseat, including the ability to dynamically add and remove seats as devices are added and removed. Full logind multiseat support has been added to gdm, but not yet to LightDM.

Adding multiseat support to LightDM confers several benefits:




Last consulted

Robert Ancell

LightDM project maintainer


User stories

Smooth upgrade

In lightdm.conf on my Ubuntu 12.04 "precise" system, I called the seat configuration section [Seat:MySeat] instead of the default [Seat:0]. I don't want anything to break when I upgrade to the latest LightDM.

Implications: The default name of the seat (in the XDG_SEAT sense) can't be derived from the [Seat:*] section title in lightdm.conf or else XDG_SEAT will get the wrong value and the display server might be invoked with an incorrect configuration.

Smooth upgrade #2

I share a uniseat Ubuntu 12.04 "precise" system with another family member. We each have our own system account and use fast-user-switching to switch between our login sessions. To avoid the hassle of logging in, we edited lightdm.conf so that when the computer boots, two X sessions are automatically started and our two accounts are automatically logged in. I don't want this to break when I upgrade to the latest LightDM.

Implications: It must be possible to have multiple [Seat:*] sections that are associated with the one XDG seat that is capable of VT switching (seat0).

need more user stories

Constraints and Requirements


Nice to have

Must not

Out of scope


A new xdg-seat setting identifies the logind seat name and determines how to start the display server. For a seat associated with the Linux VT system (only seat0 for now, but kmscon will change this), LightDM will launch the display server with command-line arguments that cause it to be associated with an automatically chosen VT. For a seat not associated with the VT system (non-seat0 seats), LightDM will launch the display server with command-line arguments that cause it to run independent of the VT system (e.g., use X's -sharevts argument).

See the Multiseat wiki page for more details.


UI Changes

New xdg-seat=<name> setting
(Default: seat0) This tells LightDM the name of the seat, which is used:

New use-vt=auto|true|false|<integer> setting (nice-to-have)
(Default: auto) This tells LightDM which VT to associate with the display server (if any).

New [seatFoo] section support (nice-to-have)
A section [seatFoo] would be equivalent to:


The purpose of adding this would be to make configuration less confusing to users (the config section name would match the XDG seat name). The [Seat:Foo] syntax would still be supported, but deprecated.

A section [seatFoo:Bar] would be equivalent to:


Note that the colon and everything after it is ignored for the purposes of the XDG seat name. This makes it possible to declare multiple sessions for the same seat.

The full syntax is: [seatName] or [seatName:sessionName] where seatName must begin with seat and must not contain a colon.

Code Changes

If xdg-seat is unset or seat to the empty string, behave as if it was set to seat0.

If logind says that the seat named by xdg-seat doesn't exist, then an error is logged and no graphical display server is started for the seat. (Risk: What if logind is just slow to detect the seat? Mitigation: Until automatic multiseat is implemented, always assume the seat exists, even if logind says otherwise.)

Otherwise, if logind says that the seat named by xdg-seat is not suitable for graphical sessions, then an error is logged and no graphical display server is started for the seat. (Risk: What if LightDM starts before the video card is detected? Mitigation: Until automatic multiseat is implemented, assume that the seat is suitable for graphical sessions.)

Otherwise, if xdg-seat is set to seat0, then:

Otherwise, if xdg-seat is set to something other than seat0, then:

If lightdm.conf defines two or more seats with the same xdg-name, and multiple sessions are not supported on the named seat (as determined by querying logind), an error message is logged and the second and subsequent seats with that name are ignored.

The use-vt setting behaves as follows:

Also: Call set_seat_can_switch() with the value of the org.freedesktop.login1.Seat.CanMultiSession dbus property for the seat.

Note: Seat startup order shouldn't matter because the seats should be completely independent of each other. The non-VT seats shouldn't interfere with the VT seat. If there are multiple sessions declared that are associated with the same seat, then session startup order for that seat does matter (the last one started will be the active session on that seat).


No migration required (config file is backward compatible).

Test/Demo Plan


Unresolved issues

Determining a seat's multisession support from logind

The logind dbus Seat objects have a CanMultiSession property to indicate whether the seat is capable of VT switching or not. Is the value of this property valid before the display server is started? Or does logind determine this from the XDG_VTNR PAM variable set by the display manager when it starts the display server?

If the property is valid before the display server is started, then instead of checking whether the seat is named seat0 or not in order to determine how to invoke the display server, the test can be whether CanMultiSession is true or not. This would allow LightDM to support fast-user-switching on all seats without any changes once kmscon is installed.

Update: David Herrmann is working on a way to support non-VT session switching. This would enable fast user switching on seats besides seat0. If/when this is incorporated into systemd, the CanMultiSession property will be true even though the display server should not run associated with a VT. Thus, comparing the seat name to seat0 is currently the best option for determining whether to invoke the display server associated with a VT or not. Perhaps the logind API will be expanded in the future to indicate which seat (if any) is associated with the VT system.

No greeter respawn if seat's `can_switch` is false

For seats where fast-user-switching is not supported (because VT switching isn't available), the seat's can_switch property must be set to false. Unfortunately, when this is false, LightDM won't respawn a greeter on that seat after logging out. A fix for this will have to be figured out.


LightDM/Specs/BasicMultiseat (last edited 2013-08-29 04:49:09 by rhansen)