Possible Wayland Extension to publish Mouse Pointer Size

[Simon Ser]

On Wednesday, October 10, 2018 4:48 PM, Michael Arnold <myk321 at gmail.com> wrote:
> With regards to using XCURSOR_SIZE, I worry that this approach is going to
> enjoy varying levels of support across desktops and applications over time,
> for example
> 1.  Fedora 28, that has Gnome on Wayland as the default desktop, but does not
> set XCURSOR_SIZE.

That's normal, it's not included in any kind of standard right now, and only Qt
and X11 apps support it.

> 2.  Tools like gsettings need to be changed to update XCURSOR_SIZE and
> XCURSOR_THEME when the user changes the associated parameters.
> This will take time.

Yeah, I don't expect this solution to support live updates. That's a good point
in favor of a protocol.

> 3. Desktop application maintainers are poorly positioned to detect and set the
> appropriate cursor size when the Qt application starts because, like the
> toolkit maintainers, they face a variety of Wayland desktops each with a
> different mechanism for setting the mouse pointer size.

I don't understand this one. App developers shouldn't have to worry about this,
the toolkit should pick XCURSOR_{SIZE,THEME} automatically.

Anyway, we both agree that a protocol is needed.

> > The client would for instance ask "I want the default cursor image for
> > seat0" and the compositor would create a wl_buffer containing it
>
> This approach makes the most sense to me.  It means that the compositor hides
> their mouse pointer library behind a standardised Wayland extension and thus
> the compositor's mouse pointer library and settings tools can evolve
> independently of the applications and their toolkits.

Indeed, that's the idea. So we must be careful not to expose xcursor specifics
in the protocol.

> > ...do we expose an enum with a list of cursor images or do we allow clients
> > to load arbitrary cursor images?
>
> Following the logic above, the enum's make more sense to me: I see that
> XCursor has a cursor type and sub-type (to indicate size) associated with each
> pointer image and Qt has a list of pointer types
> (http://doc.qt.io/qt-5/qcursor.html).  Possibly we could use these as basis.

That makes sense to me. Note that not all cursor themes support all cursors.

> If the application wants to load its own mouse pointer, it can do that,
> possibly with the toolkit's help, if available.

Yeah, apps can always use the current set_cursor request with a custom buffer.

> > How do we handle HiDPI?
>
> Create an array of wl_buffers, one for each screen, where each wl_buffer holds
> the mouse pointer in the associated screen's resolution.

Right, so we need to add a "scale" parameter in the protocol somewhere.

> I see XCursor also supports animated cursors via multiple mouse pointer images
> and an image sequence.  To support this, we'll need a count of the number of
> wl_buffer images provided.

Aye.