Multi-seat architecture for multi-user
This is architecture proposal for multi-seat multi-user architecture, primarily targeted for IVI use cases, but could potentially be used in other multi-seat setups with minor modifications.
This document complements/replaces the device and display management parts of the https://wiki.tizen.org/wiki/Multi-user_Architecture because it doesn't fulfill the simultaneous multi-seat requirements properly, especially in terms of input methods and device allocation.
Instructions for multi-seat proof-of-concept implementation on Tizen IVI can be found at Multiseat setup.
- Support separate user sessions on each seat
- Allow user sessions to be re-seated
- Allow managed (privileged) applications outside user sessions and seat bindings (GENIVI)
- Bind set of devices to seats and active sessions
Proposed model is based on already existing multi-seat model and support of udev, libinput, systemd/logind and weston. Some further implementation is needed on certain areas in logind and weston, but no major architectural overhaul is needed and there are no design conflicts.
GPU and some other shared system device resources such as shared audio devices are managed under special user session on seat0. This is also the separately managed "GENIVI seat".
Devices belonging to specific seats are assigned under higher seats, starting from seat1. Normal user sessions are bound to these seats. Shared resources are accessed through nested subsystems.
This model allows straightforward prioritization of the sessions, including the special seat0 session and it's processes.
There is a one top-level weston running with DRM backend within the special seat0 session, shell used on this weston instance manages the render location of seat-specific content (nested westons). Any special applications running outside of the normal user session and possibly with realtime requirements can be hosted on this weston, such as dashboard/HUD.
Within each per-seat user session, there is another weston instance with a special wayland-backend that is capable of attaching to the per-seat input devices as exposed by udev. Nested weston is automatically confined to the seat space and can be re-seated. Applications running within the user session render to this weston instance.
This design can be further modified/extended with a "wayland-proxy" that would forward wayland rendering to the main weston, while locally managing input devices, to allow nested wayland access and composition without local root window. This component is not implemented yet.
In case there are separate GPUs available for each seat, normal DRM backend can be used on the session-weston on those seats where separation between managed top level (realtime) compositor and sub-compositor is not needed.
Multi-user multi-seat setup is in progress and details can be found at Multiseat Setup
There is a system instance of PulseAudio, which manages sound cards that are assigned to seat0 (i.e. shared devices not bound to any physical seat), and one PulseAudio server for each logged-in user, which manage sound cards that are assigned to some physical seat. If the user moves from one physical seat to another, that user's PulseAudio will automatically stop using the sound cards of the old seat and start using the the sound cards of the new seat.
The reason why we need the system instance is that if the system has any shared sound cards (e.g. speakers), it's impossible for two users to use the same sound card simultaneously if we only have the per-user instances. The reason why we need the per-user instances is that otherwise we would lose per-user preferences in PulseAudio and per-seat sound cards would not be confined only to the current user of that seat.
User applications connect to the per-user PulseAudio instance. If user applications need to use a shared device, the per-user PulseAudio instance will create a proxy device for the shared device, and the proxy device connects to the real sound card in the system instance via PulseAudio's tunnel module.