Cursor shapes, server-side cursor themes

The problem

Wayland handles cursor graphics on the client-side. This has several annoying implications/issues:

• It requires most clients to redundantly load a cursor theme for it to look decent, which can take up as much as 8 MB extra per client, for no good reason.
• In many cases, the cursor theme and size isn't consistent across apps, as it needs to get those from the XCURSOR_SIZE and XCURSOR_THEME environment variables, or from gsettings (which is a GNOME thing and annoying to have as dependency just for some cursors), and even that isn't so predictable (see here and here).
• Real time cursor changes are poorly handled everywhere. GTK does it the best, but it only refreshes the cursor theme when your mouse enters the window, not when it's already above it.
• Don't want to use Xcursor? Too bad! The compositor doesn't have a choice.
• Related to the above point, there's no distinction between a HiDPI or a user/compositor-defined size. A magnifier feature can't display a high or low resolution cursor however it likes. Though proper fractional scaling could solve this...
• Can't have different configured sizes and themes for multi-seat. Multiple cursors have to look the same or you run into crazy inconsistency.
• What happens when you run a Wayland compositor under another, and the small one has a different cursor theme than the one you're running it under? Then it can't just use the cursor theme of the compositor it's running under.
• What if you wanted some inverted cursors like in Windows? Oh no.
• The compositor needs to load a cursor theme anyway, for when the cursor hovers over the background (unless that's a layer shell client), or the cursor wants to display a loading animation globally.

The solution

I don't believe xcursor-configuration is the right solution. You can tell the client all the little details about how the cursor should look, but ultimately the compositor knows best. Chromium has a protocol for simply setting the cursor shape, which I think solves the aforementioned problems in the best way, by leaving the cursor theme and size to the compositor.

Another way to handle cursor shapes would be to allow the compositor to export cursor surfaces, but it remains to be seen how good of an idea that is.

It needs to be mentioned that being able to set a custom cursor surface is still nice, and useful, and should still be implemented in Wayland compositors.

Compositors that don't implement such a protocol will likely need to rely on a fallback in libwayland-cursor, which hopefully won't get in the way.

I hope you can understand my concerns.

More information in this thread

Drew Devault doesn't like it either