Multi-Pointer or Multi-Cursor to use with Wayland?

I loved and even flexed how I can use multiple mice and keyboards together in Gnome X11 with the xinput create-master [name] and xinput reattach [slave device name or id] [master device name or id] commands.

Making you able to use two mice with each having its own Keyboard focus. This was never or partly possible with a bug in Plasma 5 X11 as the Mouse Cursor did fight with the location.

Its still kind of possible now in Wayland by having a Wacom Tablet and a Mouse, which automatically creates a custom cursor for the Tablet, but it still fights in Plasma 5 Wayland for the position like it does with Plasma 5 X11 custom xinput setup. In Gnome not which shows that the feature should be possible.

It would be great if it would be possible to set any Mouse as a new custom Cursor with each having its own Keyboard focus (to set) like it was possible with Xinput.

Especially for Plasma 6 I can imagine this as a very great feature for being more productive on the same PC or better teaching by using a second input and the application twice next to each other.

Additionally, I would even donate 20€ to KDE or smth for this feature, as I see a greater future in Plasma with this feature.

Sponsored Work - KDE Discuss :slight_smile:

Here is a multi cursor example for wayland, there are few minor bugs but might worth having a look.

githubcom/ozinal/wayland-multi-cursor

I mean, while it’s interesting to finally see an alternative to xinput for wayland in Gnome, It’s still hard to imagine that the mouse cursors could render for itself in KDE or even have their own parallel custom focus like in Gnome.

But I created this post to just be able to have two mice like in your github.

I wonder how much work it would be to integrate this feature into kde, as wayland compositors are wildly different afaik.

Based on my analysis, integrating multi-cursor into KDE is actually more feasible than you might think - probably easier than your Mutter implementation.

Why KDE might actually be easier:

KWin has better abstractions for this. They already have a CursorItem system that’s designed to handle multiple cursors (they use it for per-screen rendering). You’d basically be repurposing existing infrastructure - creating cursor items per-device instead of per-screen.

The device detection code from your Mutter patch (the libinput/USB bus type stuff) transfers almost 1:1. KWin also already tracks per-device positions for tablets, so you’re not building from scratch.

The realistic path:

  1. Detect USB mice separately
  2. Create multiple CursorItem instances in the scene graph
  3. Wire up position tracking
  4. Fix the bugs (cursor icons syncing, ghost cursors on disconnect)

The KDE devs are pretty receptive to contributions. I’d suggest reaching out on their Matrix/IRC (kwin) with your Mutter work as reference - they’ll probably be excited someone’s tackling this and might even help with the architecture.

How does apps handle hover and cursor shape when multiple cursors enter the same window?

I’m interested in this too, I was actually working on some enhancement to my mcp desktop controls trying to do just that to invoke a second mouse to see what it’s grabbing, particularly since it has a hard time grabbing the right areas to click about naturally when invoking a remote desktop session for control. It can invoke its own ghost mouse it seems, but not a second visible mouse to control like my own, or so Codex told me… Maybe it was wrong.