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
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.
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:
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:
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.
(discussion continued from /code.launchpad .net/~a7x/ lightdm/ multiseat/ +merge/ 178511>)
<https:/
Laércio de Sousa (lbssousa) wrote on 2013-08- 16T12:15: 29Z:
> Robert Ancell (robert-ancell) wrote on 2013-08- 13T05:21: 32Z: .login1. Manager. SeatNew( ) triggers (on demand/dynamic
>
>> 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
> 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: .DBus.Propertie s.PropertiesCha nged() for changes .login1. Seat object properties (for when .login1. Manager. SeatNew( ) .login1. Manager. SeatRemoved( )
* org.freedesktop
in org.freedesktop
CanGraphical changes)
* org.freedesktop
* org.freedesktop
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 www.freedesktop .org/wiki/ Software/ systemd/ writing- display- managers/>)
<http://
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 multi-seat- x". It "exec"s the real X server,
> wrapper called "systemd-
> passing -sharevts automatically for non-seat0 seats, among other
> things.
The source code to this wrapper is available at cgit.freedeskto p.org/systemd/ systemd/ tree/src/ login/multi- seat-x. c>.
<http://
For seat0, invoking the wrapper is 100% identical to invoking X
directly.
For other seats (as determined by the -seat argument), the wrapper multi-session- x/<seatname> with the following contents:
creates an xorg.conf config file named
/run/systemd/
Section "ServerFlags"
Identifier "Force Input Devices to Seat"
Option "AutoAddDevices" "True"
Option "AllowEmptyInput" "True"
Option "DontVTSwitch" "True"
EndSection
Section "InputClass"
Option "GrabDevice" "True"
EndSection
Notes about this config: cgit.freedeskto p.org/xorg/ xserver/ commit/ ?id=ec1bfbc6692 6130e1153facc3b 92ee175f1cb6b6>)
* AutoAddDevices defaults to True so that line is pointless (AFAICT)
* AllowEmptyInput no longer exists (see
<http://
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.