Multi-player Wayland: Implementing Multiple Mouse Cursors on Linux

Wayland natively supports "logical seats," allowing multiple users to connect separate mice and keyboards to a single computer and control the same desktop environment simultaneously. This "multi-player" computing model enables real-time collaboration, such as pair programming or multi-user gaming, without requiring complex synchronization algorithms like CRDTs.

The Wayland Protocol and Logical Seats

The core wayland protocol is designed with multi-seat support integrated at its foundation. Every input event is linked to a wl_pointer or wl_keyboard, which are in turn connected to a wl_seat. This architecture allows the system to group input events by seat, enabling the compositor to distinguish between different users and trigger events when seats are added or removed.

It is important to distinguish between logical seats and physical seats. Logical seats allow multiple people to interact with the same desktop session (multiple cursors on one screen). Physical seats refer to a configuration where multiple users have independent screens, keyboards, and mice connected to one machine, effectively running separate sessions.

Wayland Compositor Support

While the protocol supports multi-seat functionality, implementation varies across compositors. The following table summarizes the current state of support:

Compositor Support Level Key Notes
Weston Moderate Supports multiple cursors and per-seat window focus; lacks dynamic reconfiguration.
Sway High Excellent support including per-seat window focus; cannot currently detach devices from seats.
River High Strong integration; includes a custom river-input-management-v1 protocol for seat management.
Niri Low No native support yet, though experimental forks exist.

Implementation Details

  • Weston: Requires udev rules to set the ENV{WL_SEAT} property for specific input devices. For example, assigning a mouse to a seat named "second" via /run/udev/rules.d/00-multiseat.rules allows it to operate independently of the default seat.
  • Sway: Allows runtime assignment using swaymsg seat <name> assign <input_identifier>. A known issue exists where assigning a device to a new seat adds it to the new seat rather than replacing the previous assignment, resulting in one mouse controlling two cursors.
  • River: Provides a non-monolithic approach where the window manager handles seat logic. It supports dynamic seat creation and destruction via its own input management protocol.

Graphics Library and Application Compatibility

Multi-seat support must exist across the entire stack—from the compositor to the GUI library and finally the application. Current support is fragmented:

GUI Toolkits

  • GTK (GTK4): Conceptually supports multi-seat via the get_seat method on events. However, GTK does not currently detect when new seats are added while an application is running; devices must be attached before launch.
  • SDL (v3.3.4+): Supports multi-seat features when SDL_VIDEODRIVER is set to wayland. Events include a which field to identify the seat. A limitation exists where this field is forced to 0 in absolute mouse mode; relative mode must be enabled to receive actual device IDs.

Application Observations

  • Terminal Emulators: Alacritty accepts inputs from all seats, whereas Kitty typically only reacts to the first seat.
  • Browsers: Firefox supports multi-seat interaction if launched after seats are configured, though selections still treat all inputs as a single device. Chromium does not currently react to additional seats.

Remote Collaboration via wayvnc

Remote multi-seat collaboration is possible using wayvnc (v0.8.0+), which implements the ext-transient-seat-v1 protocol. By using the --transient-seat flag, wayvnc creates a new virtual seat for every incoming connection, giving each remote user their own cursor and keyboard.

For optimal performance, users should use the --render-cursor flag to ensure all cursors are visible to all participants and the --gpu flag to enable H.264 encoding via VA-API. To further reduce latency, using a dedicated VNC client like TigerVNC is recommended over browser-based clients like noVNC.

Technical Challenges and Limitations

Implementing multi-seat support introduces significant UI and architectural challenges. Community discussion highlights several critical hurdles:

"This also breaks assumptions GUI toolkit and applications make about only one of their windows being focused at a time: gtk_application_get_active_window, QApplication::activeWindow, etc."

Key technical obstacles include:

  • Per-Seat Focus: Applications must implement a per-seat version of window focus to allow different users to interact with different UI elements simultaneously.
  • Input Assumptions: Many legacy GUI toolkits assume a single global pointer, leading to bugs where one user's action (like resizing a window) may block another user's input.
  • Focus Management: Determining the "correct" behavior when one user closes a window that another user is currently dragging is a complex edge case for compositor developers.

Sources