ubuntu-multiseat team mailing list archive

[Richard Hansen <ubuntu-a7x@xxxxxxxxxxxxxxx>]

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".  Those two
  steps are required for automatic multiseat support (dynamically spawning
  and terminating greeters as seats come and go), which is out of scope
  for this blueprint (see bug #1190581).
  
  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/
  
  ** Terminology
  
    - display server:  an instance of X, Mir, a Wayland compositor, etc.
  
  For other terms, see [3].
  
  [3]
  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 [4] 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.)
  
  [4] 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 [5] for more
  information.
  
  [5]
  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 [5], 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
+ 
+ ** 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
+ 
+ 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)
+ 
+ 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)
+ 
+ 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.
+ 
+ ** 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.

-- 
Basic Multiseat Support
https://blueprints.launchpad.net/lightdm/+spec/multiseat