ubuntu-multiseat team mailing list archive

[a7x <1190581@xxxxxxxxxxxxxxxxxx>]

(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.
If it is impossible to invoke X in this way, a bug should be filed (as
Robert Ancell suggested).

Similarly, it must be possible to invoke Mir (or a Wayland compositor,
etc.) in a way that it never touches a VT.

If/when kmscon happens, this will probably all change (for the
better).

> BTW, for automatic multiseat capable DMs, logind provides a X
> wrapper called "systemd-multi-seat-x". It "exec"s the real X server,
> passing -sharevts automatically for non-seat0 seats, among other
> things.

The source code to this wrapper is available at
<http://cgit.freedesktop.org/systemd/systemd/tree/src/login/multi-seat-x.c>.

For seat0, invoking the wrapper is 100% identical to invoking X
directly.

For other seats (as determined by the -seat argument), the wrapper
creates an xorg.conf config file named
/run/systemd/multi-session-x/<seatname> with the following contents:

    Section "ServerFlags"
            Option "AutoAddDevices" "True"
            Option "AllowEmptyInput" "True"
            Option "DontVTSwitch" "True"
    EndSection
    Section "InputClass"
            Identifier "Force Input Devices to Seat"
            Option "GrabDevice" "True"
    EndSection

Notes about this config:
  * AutoAddDevices defaults to True so that line is pointless (AFAICT)
  * AllowEmptyInput no longer exists (see
    <http://cgit.freedesktop.org/xorg/xserver/commit/?id=ec1bfbc66926130e1153facc3b92ee175f1cb6b6>)
    so that line is pointless too
  * DontVTSwitch reduces how much X will touch VTs, which is important
    since only seat0 should touch VTs
  * GrabDevice (see the evdev(4) man page) keeps input events from
    going to the console, which is important because these instances
    of X aren't bound to a virtual terminal

The wrapper then invokes X with the following command-line arguments
appended to the original arguments provided to the wrapper:

    -config /run/systemd/multi-session-x/<seatname> -sharevts

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.

The description on the "Writing Display Managers" page says that the
wrapper handles graphics device enumeration, but that's no longer
true.

-- 
You received this bug notification because you are a member of Ubuntu
Multiseat, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1190581

Title:
  Support logind's automatic multiseat feature

Status in Light Display Manager:
  Triaged
Status in “lightdm” package in Fedora:
  Unknown

Bug description:
  Now that initial logind support
  https://bugs.launchpad.net/lightdm/+bug/930488 was released for
  LightDM, I'm opening this bug to request a step further: provide
  support to logind's automatic multiseat feature.

  I have absolutely no experience with D-Bus interfaces, but it seems
  that LightDM has its own D-Bus interface for seat management, so I
  don't know what would be better: replace it with logind D-Bus
  interface (if logind is present) or chaining both (e.g.: a logind's
  SeatNew D-Bus signal should trigger LightDM's SeatAdded D-Bus signal).
  Does it make sense?

To manage notifications about this bug go to:
https://bugs.launchpad.net/lightdm/+bug/1190581/+subscriptions