← Back to team overview

ubuntu-multiseat team mailing list archive

[Blueprint multiseat] Basic Multiseat Support

 

Blueprint changed by Laércio de Sousa:

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
  
  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.
- 
-   - 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.
+   - 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?
+ 
+   - 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
  
-   - display server:  an instance of X, Mir, a Wayland compositor, etc.
+   - display server:  an instance of X, Mir, a Wayland compositor, etc.
  
  For other terms, see [4].
  
  [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.
+   - 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
+   - 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.
+   - 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).
+   - '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 '-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.
+   - 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
  
  See bug #1214146.
  
  ** 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:
- 
-         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)
+   - 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
+ 
+   - '-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>
  
  (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
  
  ** 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