(Yes, my default mouse cursor is a turtle.)

Why would you even want this?

I admit that this is a somewhat esoteric way of using computers. But hear me out:

• It’s convenient for pair programming: One person can fix a bug in one window, while the other browses the documentation!
• It’s fun for games! Using multiple controllers is the norm, why not multiple mice?
• This style of multi-player computing facilitates collaboration inside of applications very naturally, without the need for complicated synchronization algorithms.

Summary

Here’s an overview of how well “multi-seat” is currently supported in various software:

Table of contents

Terminology

I’m going to use the term “seat” a lot in this post. It describes input devices that are grouped together, to be used by the same person. For example, you could have two people in front of one computer, and each one has their own mouse and their own keyboard. In this setup, there would be two “seats”, and every seat has one mouse and one keyboard:

• seat0
  • Laptop touchpad
  • Laptop keyboard
• seat1
  • External mouse
  • External keyboard

Careful though – people use this term in two different ways:

Logical seats

The type of seat I’m interested in is sometimes called a “logical seat”. This is where multiple people are in front of one computer, and each have their own mouse/keyboard, but they control the same desktop environment. As in, the desktop shows multiple mouse cursors! The people can “hand over” windows to each other, draw together into a whiteboard application, or directly collaborate within the same software. (Not that all of these things would be possible right now, but, you know, conceptually!)

I think there could be a term that’s describing this concept even better – in the title of this post, I picked “multi-player”, to make clear that it’s mostly about multiple people who are collaborating. I’ve also seen “multi-cursor” or “multi-pointer” (which are missing the keyboard component).

Physical seat

The term “seat” can also mean something else, which is called a “physical seat”: This refers to setups where there are multiple people who all have their own independent setup: A screen, a keyboard, a mouse. They don’t really interact with each other, but the input and output devices are connected to a single computer. This is what Wikipedia is referring to in the Multiseat configuration article.

But this is not what this post is about. If you know more about the current state of support on Linux, I’d encourage you to write your own blog post on it!

Overview

I only investigated the situation on Linux, and specifically on Wayland (a modern graphical display system). X11 (the X Window System) has its own multi-seat extension called Multi-Pointer X (MPX), which I also had a lot of fun with a couple of years ago.

But at this point, I’ve moved on to Wayland compositors in my everyday computer usage. And it turns out that Wayland has great built-in support for multiple seats!

I’ll talk about how to set up a multi-user system, what Wayland protocols are involved, and finally, what the current application support looks like.

The tricky thing is that multi-seat support has to be present at every layer:

1. The Wayland compositor (which usually contains the window manager).
2. The wayland protocol.
3. The GUI library used by the graphical application.
4. The graphical program itself.

Optionally, if you want to allow people to collaborate with you remotely, the program you use to allow them to connect (like a VNC server) requires multi-seat support, as well. I’ll later show how to set this up!

So we’re going to look at all of those layers, starting with the wayland protocol itself.

The wayland protocol

This rabbit hole was the first time I looked deeper in what Wayland actually is! At its heart, it’s a collection of protocols. I was really happy to find that the core wayland protocol (that graphical programs and the Wayland compositor use to talk to each other) has deeply integrated multi-seat support:

Every input event is connected to a wl_pointer or wl_keyboard, which in turn are connected to a wl_seat. You can then use this information about the seats to “group” input events together! There are also events that are triggered when seats appear/disappear.

Wayland Compositors

But how well do compositors (the programs that manage the windows and draw their contents) use these concepts to speak with the client applications? I tried some:

Weston

Weston used to be the reference implementation of a Wayland compositor, and is being maintained by the Wayland team at freedesktop.org.

It was the first compositor I realized had real multi-seat support! You can have multiple mouse cursors, and each one can move around windows, independently from each other!

Weston also implements per-seat window focus, which means that if a seat has a mouse and a keyboard, the mouse can focus a window, and the keyboard will hen send its keystrokes to it – and different seats can focus different windows at the same time.

There are some fun edge cases that I found playing around with this:

• Once a cursor starts to resize/move a window, those actions are not possible for the other one.
• One cursor can open a menu, and the other one can use it, that one works pretty well!
• Closing a window with one cursor, while the other drags it, makes the second cursor disappear! :D

These are really hard (and fun) UI questions to solve! Often, it’s not clear to me what the correct behavior should be!

pkgs.sdl3.overrideAttrs (old: {
  postPatch = ''
    substituteInPlace src/events/SDL_mouse.c --replace-fail "mouseID = SDL_GLOBAL_MOUSE_ID;" "//mouseID = SDL_GLOBAL_MOUSE_ID;"
  '';
});