Multiple Mouse Cursors in Wayland

I’ve been fascinated by the idea of attaching multiple mice to one computer, and then having multiple mouse cursors inside of one desktop environment!

I just spent three weeks investigating how well that’s currently supported on Linux & Wayland. Let me tell you what I found! The results are surprisingly cool.

Together with this blog post, I’m publishing a number of little tools and patched libraries that add or improve “multi-seat” support. But many pieces in this puzzle are still incomplete or missing. I marked some “open projects ideas” with a 📝 emoji throughout the blog post. By publishing this post, I hope to find people who are interested in exploring and expanding this space together. If that’s you, reach out!

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

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

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

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:

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

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

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!

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:

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.

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.

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 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:

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

Setting up seats on Weston is quite involved. Later compositors will make it much easier!

To separate input devices into multiple seats, you need to use udev rules to set the ENV{WL_SEAT} property . Assign the same seat name to a mouse and a keyboard to make them work together! The default seat is “default”.

Create a file /run/udev/rules.d/00-multiseat.rules like this:

ATTRS{name}=="Name of your mouse" ENV{WL_SEAT}="second" (Note that there’s two = characters for testing, but a single = character for assigning.)

Now check sudo libinput list-devices again. The device’s “Seat” should now say “seat0, second”!

sway is the Wayland reimplementation of i3. Support for multiple seats was added to wlroots in version 0.1 (released in 2017), and subsequently added to sway 1.0.

sway also has excellent multi-seat support, including per-seat window focus!

You can list all inputs using swaymsg -t get_inputs and list all seats using swaymsg -t get_seats .

Then, use swaymsg seat <name> assign <input_identifier> to assign an input device to a specific seat. The seat will be created if it didn’t exist before.

Right now, this seat management has a surprising property: If you assign a device to one seat, and then to another, instead of replacing that seat assignment, it will add it. That means that you will then have two mouse pointers being controlled by a single mouse!

📝 There’s an open issue to discuss solutions for that, and I made a patch to fix this issue for myself. If you’re running that patch, you can use my multi-seat-configurator tool to quickly assign input devices to seats using a TUI!

I haven’t tried other wlroots compositors yet, if you have experience with them, please tell me about it!

River is a non-monolithic Wayland compositor that provides the compositor part, and allows you to write your own window manager! I think it’s a very cool idea.

The multi-seat capabilities are pretty good, it’s pretty much baked into everything. River also has its own river-input-management-v1 protocol that can notify you when new input devices become available, create/destroy seats, and assign devices to seats. I wrote a little Rust tool ( river-multi-seat-configurator that uses this protocol to assign devices to seats on demand.

I only tried the tinyrwm example window managers for River, which even somewhat support per-seat window focus!

📝 It would be a fun project to write a new window manager for River with first-class multi-seat support! Window focus could be highlighted with multiple colors; edge cases of interacting with the windows could be handled in a reasonable way; and there could be per-seat clipboards?

niri is my Wayland compositor of choice these days. <3 Last year, multi-seat support was requested , but the lack of application support was quoted as a reason not to add it.

I think it would be great. Some months ago, I hacked in some multi-seat support, see the multi-seat branch of my fork here .

📝 Currently, my “hacked version” only supports two seats, and there are some hardcoded device names in the code. Adding a proper “seat manager” would be the next step.

To my surprise, the GUI toolkit GTK seems to have great support for multi-seats, conceptually! Events have a get_seat method, which directly tell you which Seat an event belongs to. There doesn’t seem a way to get the seat’s name, but you can compare them to tell whether they’re different, which seems good enough.

I’ve only tested this on GTK4, but the types and methods seem to have existed in GTK3, as well.

Most GTK widgets don’t really respect multi-seat input, and mostly act as if all inputs would come from the same device. But I wrote an experimental MultiSeatText widget in Rust, see below !

📝 A bug I noticed is that while GTK notifies you when seats are removed, it doesn’t seem to notice when seats are added. Thus, for devices in a seat to do anything, they must already be attached before the program launches. I reported that issue here .

The Simple DirectMedia Layer supports some multi-seat features since v3.3.4 (released in 2025).

When you try this, make sure to set the SDL_VIDEODRIVER environment variable to wayland . SDL seems to fall back to XWayland otherwise in my tests.

Events like SDL_MouseButtonEvent or SDL_KeyboardEvent have a which field, that’s different if the events come from different seats. You can also tell when devices are plugged in or out from SDL_MouseDeviceEvent and SDL_KeyboardDeviceEvent , which carry the same which field.

The device IDs are arbitrary unique IDs that are not reused when plugging devices out and back in. To learn which seats the devices belong to, you can use the SDL_GetMouseNameForID and SDL_GetKeyboardNameForID functions. They will report names like “Virtual core pointer (default)” or “Virtual core keyboard (second)”, for example, where the part in the parentheses is the name of the seat.

📝 There’s a caveat: The which field in mouse events will be forced to 0 when the mouse is in the (default) absolute mode. You have to activate relative mode in order to get which fields with actual device IDs. I opened this issue to find out why that is, and the answer was “for consistency, to match the behavior on other platforms”.

The patch to also get the which field in absolute mouse mode is simple: Just comment out all lines that say mouseID = SDL_GLOBAL_MOUSE_ID; in src/events/SDL_mouse.c . Here’s a snippet of Nix code that you can use to make a patched version of this yourself (if this seems confusing, feel free to email me, and I’ll help/expand this!):

pkgs.sdl3.overrideAttrs (old: { postPatch = '' substituteInPlace src/events/SDL_mouse.c --replace-fail "mouseID = SDL_GLOBAL_MOUSE_ID;" "//mouseID = SDL_GLOBAL_MOUSE_ID;" ''; }); LÖVE I’m a big fan of the LÖVE 2D game engine, and I wanted to make some multi-seat games with it. LÖVE is based on SDL, so I made a patched version of LÖVE where the which field is forwarded to the event callbacks in Lua!

My repo contains a Nix flake that also bundles my patches to SDL. You can try it by installing Nix and running nix run github:blinry/love/multi-seat (it will need to compile both SDL as well as LÖVE).

You can find an example of a game made with this further down in this post!

📝 I haven’t investigated any other GUI frameworks yet! If you know something about them, please let me know!

I’m not aware of any existing end-user applications that make use of multiple seats at the moment. For X11, there was Gromit-MPX , a screen annotation tool, but it doesn’t seem to support native Wayland.