Unfortunately, the term session is overloaded. As per POSIX, a session is a collection of one or more process groups.
On modern system, every instance of a "user login" is also called a session. More general, every set of programs with the permissions of one user is considered a session. For example: Each login to a tty is an own session. Each user supervision tree running as a leaf of the system supervision tree is a session. For the following consideration the latter defintion will be used.
Each session has acces to 0, 1 or more seats (see below).
With goetia, a session is most of the time a user supervision tree. The actual user interface, e.g. the Wayland compositor is then a user service in this user supervision tree.
A seat is a virtual object representing a set of input devices (e.g. keyboard, mouse) and output devices (e.g. GPU with attached monitor, sound card). If any session is "attached" onto a seat, it may write to the output devices and read from the input devices.
Multisession describes the process of starting two or more different sessions, and alternately attaching them to a seat. For example:
A on seat S.
A in the background.
That is, revoke the capabilities of A
to read from an write to input and output devices
that form seat S.
B on seat S.
B in the background.
That is, revoke the capabilities of B
to read from an write to input and output devices
that form seat S.
A in the foreground again,
allowing it to read from and write to
the devices of seat S again.
In practise, this manifests in the user seeing
either the X server of session A
or the Wayland compositor of session B
and switches between them by pressing some key combination
or executing a command.
Another example is switching to a getty (ctrl + alt + FN)
to fix a broken X session.
Multiseat is the process of having one computer, with two or more seats, each seat having at least one session. As an example, this allows two people to use one computer as if it were two computers.
Having multiple sessions at once trying to
access the same hardware (seat),
poses the following problem:
Once session A is backgrounded,
its programs need to release the hardware devices,
otherwise it still reads the hardware input
(e.g. the typing) intended for session B.
Additionally it would still write to the screen,
yielding a mixture of the output of A and B.
To solve this problem,
there is a Kernel interface called "virtual terminals".
Switching between these is what is traditionally happening
upon pressing ctrl + alt + FN.
each virtual terminal N
represents one session.
Virtual terminals are a very old solution and have
the following problems:
For this reason a program (or a better in Kernel solution) is needed. This is solved by seat/session managers. Session management is just a special case of seat management (assigning one seat to multiple sessions instead of multiple seats to multiple sessions). Thus, all solutions are called seat managers.
A seat manager mediates access to the hardware devices. That means, the graphical interface will ask the seat manager for a handle of that device. The seat manager can always revoke those handles, even if the graphical interface is hung up. Additionally, it can handle multiple seats.
Examples of seat managers are:
The
source directory
for seatd is included in
goetia-base,
that for elogind in
goetia-linux.
One of them should be chosen and added to the
seat-manager bundle.
The following articles provide more examples of seats, sessions and the other concepts mentioned. They are systemd centric, but the basic concepts carry over.