Introduction

This page is intended to provide some background information about how multiseat systems work in the Linux world.

The MultiseatX page contains details for configuring multiseat X systems. Eventually information for non-X (Mir, Wayland) setups will be added to this page or separate pages.

If you are interested in improving multiseat support in Ubuntu, please consider joining the MultiseatTeam.

What is Multiseat?

Multiseat refers to a single machine with multiple "seats" allowing multiple users to sit down at the computer, log in, and use the computer at the same time. The computer has multiple keyboards, mice, and monitors attached. Each seat has (at least) one keyboard, mouse, and monitor assigned to the seat.

Multiseat setups are great for schools, libraries, and family computers.

See the Wikipedia "Multiseat configuration" page for more details.

Terminology

• display server: an instance of X, Mir, a Wayland compositor, etc.

For other terms, see the definition of terms section of the freedesktop.org multiseat page.

Mir and Wayland

With regard to multiseat, the high-level designs of Mir and Wayland are similar enough to X that all of the high-level concepts here also apply. Thus, the term "display server" is used instead of "X" when the idea is broadly applicable.

Multiseat and Virtual Terminals

This section describes some of the technical concepts behind Linux multiseat systems. Virtual terminals play a prominent role.

Summary of how it works

By default, display servers are designed to cooperate with Linux's VT system. They participate in VT switching, allowing the user to switch to text-based virtual consoles or other display servers by pressing Ctrl-Alt-F?.

However, Linux's VT system is uniseat---it doesn't understand the concept of multiple physical consoles attached to the same computer.

Multiseat systems work despite this limitation because at most one display server is associated with the VT system. The display servers for the other seats are configured to run independently from the VT system. These other display servers steal control over some of the input and display devices from the VT system so that they can use them for their own purposes.

If configured correctly, the display server associated with the kernel's VT system is the only one that can participate in VT switching. The other seats are unaffected by VT switches, and they can't initiate VT switches or otherwise interfere with the VT system.

Linux Virtual Terminals

Linux and other Unix-like operating systems have a feature called Virtual Terminals (or VTs for short). This feature allows a single physical console (keyboard and display) to switch between multiple logical consoles. This allows a user to log in multiple times to the same computer and do something different in each session.

In Ubuntu, virtual terminals 1 through 7 are usually defined. VTs 1 through 6 are text-based Linux consoles and VT 7 is the graphical X console. Virtual terminals can be created and destroyed dynamically.

A keyboard sequence is used to switch between the virtual terminals. When in X, Ctrl-Alt-F? is used. When at the Linux console, either Ctrl-Alt-F? or just Alt-F? work.

The Linux VT system: only one seat

The VT system in the Linux kernel does not understand the concept of multiple seats. According to the kernel, there is only one physical console, and there is always just one active VT. Unless a program (like X) steals away a keyboard from the kernel VT system, all events from all keyboards feed the same active VT.

In the future, if/when kmscon happens, the Linux kernel will be able to support multiple physical seats. This will allow each seat to have its own independent set of virtual terminals. The number of active virtual terminals will equal the number of seats.

Multiseat is possible despite the current limitations in Linux's VT system because the display server can steal control over some input and graphical devices from the Linux VT system.

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 to another VT, the display server essentially releases control over the input and video devices so that they can be used by the other VT. 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 complete 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 VT 7 and another seat's display server is running on VT 8, 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 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.)

How multiple seats are managed

The role of the display manager

todo

Assigning devices to seats

todo

Tracking seats

todo

Tracking sessions

todo

Program-specific details

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).

Running without an associated VT

To run X without an associated VT:

• the -sharevts argument must be used

• the following configuration snippet must be 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

X talks more-or-less directly with hardware devices. In order to do this, each instance of X must know which devices it is associated with.

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 the udev rules section of the freedesktop.org multiseat page for more information.

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 in the udev rules section of the freedesktop.org multiseat page, 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.

CategoryMultiseat