ubuntu-multiseat team mailing list archive
-
ubuntu-multiseat team
-
Mailing list archive
-
Message #00101
[Blueprint multiseat] Basic Multiseat Support
Blueprint changed by Richard Hansen:
Whiteboard changed:
- * Introduction
-
The protocol for interacting with logind in a multiseat environment is
described at [1]. I define "basic multiseat support" to be everything
documented there except steps 1 and 2 of "complete porting".
Also see "Multiseat on Linux" [2].
[1] http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/
[2] http://www.freedesktop.org/wiki/Software/systemd/multiseat/
- ** Related future work
+ = Background =
+
+ See: https://wiki.ubuntu.com/Multiseat
+
+ = Related future work =
The following are not considered to be part of this blueprint. They
should be tackled separately.
- - Steps 1 and 2 of "complete porting" in [1]. Those two steps are
- required for automatic multiseat support (dynamically spawning and
- terminating greeters as seats come and go). See bug #1190581.
+ - Steps 1 and 2 of "complete porting" in [1]. Those two steps are
+ required for automatic multiseat support (dynamically spawning and
+ terminating greeters as seats come and go). See bug #1190581.
- - A tool to make it easier for users to assign devices to seats via
- udev rules.
- [EDIT Laércio de Sousa] What about loginctl (part of systemd)? We can do something like "loginctl attach seatXXX /sys/devices/path/of/device" to assign a device to a seat. We can also see the list of assigned devices with command "loginctl seat-status seatXXXX". Is loginctl currently packaged in Ubuntu?
+ - A tool to make it easier for users to assign devices to seats via
+ udev rules.
- - Fixing X so that the logind multiseat wrapper [3] can be replaced
- with appropriate command-line arguments.
+ Note that systemd's loginctl utility, available in Ubuntu since
+ 13.04 raring, has an "attach" feature that is intended to make it
+ easier to assign devices to seats. I have not tested this feature
+ to see how or even if it works. Getting this utility to work with
+ Ubuntu, or improving its functionality, is out of scope for this
+ blueprint.
+
+ - Fixing X so that the logind multiseat wrapper [3] can be replaced
+ with appropriate command-line arguments.
[3] http://cgit.freedesktop.org/systemd/systemd/tree/src/login/multi-
seat-x.c?id=v206
- ** Terminology
+ = Requirements =
- - display server: an instance of X, Mir, a Wayland compositor, etc.
+ - follow steps 1-4 of "minimal porting" and steps 3-4 of "complete
+ porting"
+ - support X, Mir, Wayland compositors, etc.
- For other terms, see [4].
+ = Work Item descriptions =
- [4]
- http://www.freedesktop.org/wiki/Software/systemd/multiseat/#definitionofterms
-
- ** Requirements
-
- - follow steps 1-4 of "minimal porting" and steps 3-4 of "complete
- porting"
- - support X, Mir, Wayland compositors, etc.
-
- ** Mir and Wayland
-
- I am not very familiar with alternative display servers such as Mir and
- Wayland, but I believe their designs are similar enough to X with regard
- to multiseat that all of the concepts in this blueprint also apply.
- Thus, I will try to use the term "display server" instead of "X" when
- the core idea is broadly applicable.
-
- * Background: Multiseat and Virtual Terminals
-
- ** Associating with a VT
-
- A display server can associate itself with a VT. For example, by
- default X will discover an unused VT at startup and switch to it. When
- it exits, it switches back.
-
- When the display server is associated with a VT, it will allow the user
- to switch to another VT at any time (e.g., by pressing a Ctrl-Alt-F? key
- sequence). When the user switches away, the display server releases
- control over the input and video devices so that they can be used by
- another virtual terminal. When the user switches back, the display
- server re-acquires control over the devices.
-
- Note that a different display server could be running concurrently on
- another virtual terminal. When the user switches to the other display
- server, the virtual terminal system acts as a mediator, coordinating the
- handoff of control over the input and video devices. This is how fast
- user switching is currently implemented.
-
- ** Running independent of a VT
-
- A display server can also be invoked in such a way that it does not
- associate itself with a VT. It simply acquires control over some or all
- input and video devices. Because the display server is not associated
- with a virtual terminal, fast user switching is not supported -- there
- is nothing mediating the release and acquisition of control over the
- devices.
-
- When a display server is not associated with a VT, it must not:
- - probe to see what the current VT is
- - attempt to switch VTs
- - let a VT see the seat's input (keyboard, mouse) events
-
- Note that any devices not controlled by the display server would still
- be available for use by the Linux virtual terminal system.
-
- ** VT limitations
-
- The Linux virtual terminal system only supports a single seat. This
- makes configuring a multiseat X/Mir/whatever system difficult because
- only one VT can be active at any given time. If one seat's display
- server is running on vt7 and another seat's display server is running on
- vt8, then only one of these two seats can be used at a time. To use the
- other seat, a VT switch must be initiated.
-
- To make all seats usable at the same time, there are a few options:
-
- - Associate all display servers with the same VT. If any user at
- any seat switches VTs, all seats will switch to the new VT. This
- makes VT switching (and thus fast user switching) impractical.
-
- - Don't associate any display server with a VT. Fast user switching
- is impossible in this case. Text-based console logins are only
- possible if an input and display device are reserved for this
- purpose.
-
- - Associate only one of the display servers with a VT. The other
- display servers can't do VT switching, but the display server
- associated with a VT can. VT switching on that one seat won't
- affect the other seats. This is the approach favored and assumed
- by systemd, and will be the approach taken by LightDM.
-
- If/when kmscon [5] happens, the Linux kernel virtual terminal
- limitations will go away. kmscon will support multiple seats, which
- will make it possible to support fast user switching on each seat. (The
- system administrator will have to be careful to configure kmscon and the
- display manager to agree on the definition of the seat in terms of
- hardware devices.)
-
- [5] http://www.freedesktop.org/wiki/Software/kmscon/
-
- * X specifics
-
- ** Associating with a VT
-
- To run X associated with a VT, no special arguments or configuration
- settings are needed. Some useful arguments are:
-
- - 'vtXX' where XX is a virtual terminal number. This is used to
- force X to use a particular VT, rather than try to discover an
- unused VT. This argument is useful in combination with Plymouth,
- where smooth handoff of the video device is desired.
-
- - '-novtswitch' prevents X from doing any VT switching on startup
- and shutdown. LightDM passes this option to X because it does its
- own VT switching (to facilitate smooth handoff from Plymouth to
- X).
-
- ** Without a VT
-
- To run X without an associated VT:
-
- - the '-sharevts' argument is used
-
- - the '-novtswitch' is used (this might not be required)
-
- - the following configuration snippet is used to prevent X from
- attempting any VT switches:
-
- Section "ServerFlags"
- Option "DontVTSwitch" "True"
- EndSection
-
- - the following configuration snippet is used to prevent input
- events from going to a virtual terminal (see the evdev(4) man
- page):
-
- Section "InputClass"
- Identifier "prevent input events from going to the console"
- Option "GrabDevice" "True"
- EndSection
-
- The above may not be sufficient; a code audit should be done to ensure
- that the above settings are enough to guarantee that X does not do
- anything related to virtual terminals.
-
- ** Device selection
-
- When given the '-seat' argument, X will only use devices that have been
- "tagged" (via udev rules) with the given name. All other devices are
- off limits. This provides a convenient way to tell X which subset of
- input and display devices it is permitted to use. See [6] for more
- information.
-
- [6]
- http://www.freedesktop.org/wiki/Software/systemd/multiseat/#udevrules
-
- * logind specifics
-
- - seat0 is the name of the "primary" seat. It always exists. Any
- seat-specific hardware device not specifically designated to
- another seat belongs to seat0.
-
- - As documented at [6], each seat must have a device tagged (via
- udev) "master-of-seat". Without a device with this tag, logind
- assumes the seat is not ready yet. When a master-of-seat device
- appears, logind declares the seat available, signaling the display
- manager that the seat is ready for a display server. This tag
- should be applied only to the seat's video device so that the
- video device is guaranteed to be ready when the display manager
- launches the display server.
-
- * Work Item descriptions
-
- ** Package systemd-multi-seat-x
+ == Package systemd-multi-seat-x ==
See bug #1214146.
- ** New setting: xdg-seat=<name>
+ == New setting: xdg-seat=<name> ==
The xdg-seat=<name> seat setting tells LightDM the name of the seat.
The name defaults to "seat0".
This name is used:
- - in the XDG_SEAT variable (for PAM)
- - in the -seat argument to X (if the seat is an X seat and not Mir
- or something else)
- - to determine how to handle VTs
+ - in the XDG_SEAT variable (for PAM)
+ - in the -seat argument to X (if the seat is an X seat and not Mir
+ or something else)
+ - to determine how to handle VTs
If the name is unset, set to the empty string, or set to seat0, then:
- - LightDM switches to an automatically chosen VT
- - 'vtXX' is passed to X (if the seat is an X seat) where XX is the
- number of the chosen VT
- - '-seat seat0' is passed to X (if the seat is an X seat)
+ - LightDM switches to an automatically chosen VT
+ - 'vtXX' is passed to X (if the seat is an X seat) where XX is the
+ number of the chosen VT
+ - '-seat seat0' is passed to X (if the seat is an X seat)
If the name is set to something other than seat0, then:
- - LightDM does NOT do any VT switching
- - 'vtXX' is NOT passed to X (if the seat is an X seat)
- - '-seat <name>' is passed to X (if the seat is an X seat)
- - LightDM creates a temporary xorg config file with the following
- contents:
+ - LightDM does NOT do any VT switching
+ - 'vtXX' is NOT passed to X (if the seat is an X seat)
+ - '-seat <name>' is passed to X (if the seat is an X seat)
+ - LightDM creates a temporary xorg config file with the following
+ contents:
- Section "ServerFlags"
- Option "DontVTSwitch" "True"
- EndSection
- Section "InputClass"
- Identifier "prevent input events from going to the console"
- Option "GrabDevice" "True"
- EndSection
+ Section "ServerFlags"
+ Option "DontVTSwitch" "True"
+ EndSection
+ Section "InputClass"
+ Identifier "prevent input events from going to the console"
+ Option "GrabDevice" "True"
+ EndSection
- - '-config /path/to/above/config/file -sharevts' is passed to X (if
- the seat is an X seat)
+ - '-config /path/to/above/config/file -sharevts' is passed to X (if
+ the seat is an X seat)
If lightdm.conf defines two or more seats with the same name, an error
message is logged and the second and subsequent seats with that name are
ignored.
- ** New setting: use-vt=auto|true|false|<integer>
+ == New setting: use-vt=auto|true|false|<integer> ==
(this is not strictly required, but would be a nice feature in case
anyone needs to control VT associations)
The use-vt=* seat setting tells LightDM which VT to associate with the
display server (if any).
- - use-vt=true: Switch to an automatically chosen VT, pass vtXX to X,
- and do not pass -sharevts to X.
- - use-vt=false: Do not switch VTs, do not pass vtXX to X, do pass
- -sharevts to X, and generate a X config with "DontVTSwitch" and
- "GrabDevice" enabled.
- - use-vt=auto (default): If the name of the seat is seat0, this is
- the same as use-vt=true. Otherwise (not seat0), this is the same
- as use-vt=false.
- - use-vt=<integer>: Same as use-vt=true, but use the specified VT.
+ - use-vt=true: Switch to an automatically chosen VT, pass vtXX to X,
+ and do not pass -sharevts to X.
+ - use-vt=false: Do not switch VTs, do not pass vtXX to X, do pass
+ -sharevts to X, and generate a X config with "DontVTSwitch" and
+ "GrabDevice" enabled.
+ - use-vt=auto (default): If the name of the seat is seat0, this is
+ the same as use-vt=true. Otherwise (not seat0), this is the same
+ as use-vt=false.
+ - use-vt=<integer>: Same as use-vt=true, but use the specified VT.
- ** Write test cases
+ == Write test cases ==
- ** Set can_switch appropriately
+ == Set can_switch appropriately ==
- - call set_seat_can_switch() with the value of the
- org.freedesktop.login1.Seat.CanMultiSession dbus property
- - bug that needs to be figured out: If can_switch is true on a
- seat, then when you log out LightDM won't respawn a greeter on
- that seat.
+ - call set_seat_can_switch() with the value of the
+ org.freedesktop.login1.Seat.CanMultiSession dbus property
+ - bug that needs to be figured out: If can_switch is true on a
+ seat, then when you log out LightDM won't respawn a greeter on
+ that seat.
--
Basic Multiseat Support
https://blueprints.launchpad.net/lightdm/+spec/multiseat
