Rough proposal for a cursor-geometry protocol

[Campbell Barton]

Hi, I've been maintaining Blender's Wayland integration and have run 
into issues with cursor size being too big/small.

At first I thought it could be overlooked (treated as more of a glitch),
however in the worst case this is an accessibility issue, one user for
example found the cursor was so small it was difficult to see in their 
system [0].

Furthermore, as a user of wayland I notice my cursor changing size all 
the time - it seems each window has a different method of calculating
the cursor size, so moving the cursor between applications will show
at a different size for each.

Note that the cursor-shape-v1 API is good, but doesn't solve the problem 
when the application defines custom-cursors.

Currently we face the problem that there is no way to know the cursor 
theme/size ... or (a lesser problem) when these are 
re-configured/modified at run-time.

Existing partial solutions:

- Use environment variables XCURSOR_THEME / XCURSOR_SIZE,
   while these "work", it relies on technical users to
   manipulate their environment variables values.

- Use DBUS to access common settings used by GNOME/KDE,
   This is something we tried but ended up disabling as
   DBUS would sometimes hang for 5+ seconds on startup.
   Given we didn't use DBUS for anything else,
   it seemed simplest to disable.

   Even if this could be made to work it seems like a weak solution
   that every application needs to read desktop specific settings from
   GNOME/KDE/XFCE/Cosmic... etc.


Proposal
========

It would be useful if there was a protocol for accessing the theme/size.
With the added benefit that run-time changes could be accounted for.

If well documented, applications would have a shared method of accessing 
& showing the cursor size.

Here is a rough outline for the protocol
(name could be cursor-geometry-v1 or similar).

```
   /* Preferred callbacks: */
   preferred_theme(seat, const char *cursor_theme);
   preferred_size(seat, int cursor_size);

   /* Apply changes requested by `preferred_*` functions. */
   configure(seat);
```

Notes:

- There could be other things to configure,
   added as new `preferred_*` callbacks as needed.

- The theme & size would roughly map to:
   `XCURSOR_THEME` & `XCURSOR_SIZE`.

- These callbacks would run after registering the "seat",
   before registering "pointers",
   so the values can be used for applications on startup
   (to avoid flickering caused by cursor changes on startup).

- Changes to the cursor theme/size (GNOME/KDE... etc)
   should also re-configure the cursor.

- The size from `preferred_size` would *not* have
   scale/fractional-scaling applied so it's up to the client
   to scale the `cursor_size` based on the output scale.

   The reason not to apply output scaling
   users may move the cursor between outputs,
   meaning this call back would have to run much
   more frequently on systems with outputs with different scaling.

   While it could be made to work I believe it complicates
   using the protocol unnecessarily.

   The docs should provide the method of applying
   fractional scaling so cursor size doesn't
   change between applications).

- The *level* this protocol applies to is an open topic.
   Per "seat" seems logical to me, there may be some argument
   that this should be per: "pointer", "tablet" although I can't
   see a good reason to do that.

Regards,
- Campbell

[0]: https://projects.blender.org/blender/blender/issues/105895