Possible Wayland Extension to publish Mouse Pointer Size

[Michael Arnold]

Hi,

I'm new here and out my depth - normally I tinker together applications, on
linux, sometimes using Qt. Using Qt under Gnome/Wayland I noticed that the
mouse pointer increased in size when moved over a Qt based application.
(The defect is raised here: https://bugreports.qt.io/browse/QTBUG-70971).
As I am sure you aware, under Wayland, Qt is responsible for displaying the
mouse pointer and since there is no standard way across Wayland compositors
to determine the current cursor size, Qt sets the mouse pointer to size 32
by default. Gnome, on a none-HiDPI display (like mine), sets the mouse
pointer size to 24, hence the weird mouse pointer size change when the
mouse pointer is moved over a Qt application window where the size set to
32.

Understandably Johan (from Qt Co.) is reluctant to use gsettings to get the
current cursor size from within the Qt Platform Abstration Layer (QPA),
because that means they will need to do something similar for every Wayland
compositor and hence is suggesting (correctly from what I understand) that
a Wayland extension be created for Wayland Compositors to publish their
mouse pointer size. Qt, GTK+ etc. can then pickup the mouse pointer size
using the Wayland protocol extension and display the mouse pointer at the
current size when the mouse is over the application window.

But this is where I get a bit lost and would be grateful of your guidance:
from what I can see the xdg-decoration protocol got proposed and debated
via this mailing list. Is there someone on this mailing list who would be
interested to pickup this issue or is there some other forum where I need
to raise this request?

Kind regards,
Michael

[Simon Ser]

Hi,

On Tuesday, October 9, 2018 3:34 PM, Michael Arnold <***@gmail.com> wrote:
> Hi,
>
> I'm new here and out my depth - normally I tinker together applications, on
> linux, sometimes using Qt. Using Qt under Gnome/Wayland I noticed that the
> mouse pointer increased in size when moved over a Qt based application. (The
> defect is raised here: https://bugreports.qt.io/browse/QTBUG-70971). As I am
> sure you aware, under Wayland, Qt is responsible for displaying the mouse
> pointer and since there is no standard way across Wayland compositors to
> determine the current cursor size, Qt sets the mouse pointer to size 32 by
> default. Gnome, on a none-HiDPI display (like mine), sets the mouse pointer
> size to 24, hence the weird mouse pointer size change when the mouse pointer
> is moved over a Qt application window where the size set to 32.

Indeed, we (wlroots) have the same issue. Weston apps also choose 32, GLFW
chooses 24 IIRC.

> Understandably Johan (from Qt Co.) is reluctant to use gsettings to get the
> current cursor size from within the Qt Platform Abstration Layer (QPA),
> because that means they will need to do something similar for every Wayland
> compositor and hence is suggesting (correctly from what I understand) that a
> Wayland extension be created for Wayland Compositors to publish their mouse
> pointer size. Qt, GTK+ etc. can then pickup the mouse pointer size using the
> Wayland protocol extension and display the mouse pointer at the current size
> when the mouse is over the application window.

Agree. Using gsettings is not a viable solution.

> But this is where I get a bit lost and would be grateful of your guidance:
> from what I can see the xdg-decoration protocol got proposed and debated via
> this mailing list. Is there someone on this mailing list who would be
> interested to pickup this issue or is there some other forum where I need to
> raise this request?

If you want to discuss about improving the cursor situation on Wayland, this is
the right place.

I think we have two possible solutions: a short-term one and a long-term one.

The short-term one is already used by Qt and some X11 apps. It uses two
environment variables (XCURSOR_THEME and XCURSOR_SIZE) to configure the cursor
theme and size. I recently had a pull request merged to always export those from
the default Wayland seat's configuration in rootston, our wlroots
compositor [1]. I just opened a Weston merge request to add support for this in
Weston clients [2].

The issue with that short-term solution is that in addition to cluttering the
environment, it isn't multiseat aware. Let's say you have two seats (so you also
have at least two cursors). Then it's difficult to tell which cursor belongs to
which seat, both are identical.

To fix this, a new Wayland protocol would be required. That would be the
long-term solution. Qt and GLFW have expressed interest in such a protocol.

This protocol could just tell the client which XCursor theme/size to use for
which seat. Though, there are other issues with this approach: it requires
XCursor (wouldn't work with a different cursor image specification) and clients
still need to load cursors themselves (a thing the compositor usually already
does). Also, some of our users want to be able to change the default cursor
image (to e.g. use the same theme for two seats but have one with the left
pointer image and the other with a cross image).

I've thought about another proposal: a protocol that would allow clients to
create opaque wl_buffers containing cursor images. The client would for instance
ask "I want the default cursor image for seat0" and the compositor would create
a wl_buffer containing it. There are still many unanswered questions though:
do we expose an enum with a list of cursor images or do we allow clients to load
arbitrary cursor images? How do we handle HiDPI?

Alternatively, to only fix the cursor size issue without introducing a whole new
protocol, Johan suggested to add a "cursor_size" event to wl_pointer in the core
Wayland protocol. Pekka said he's not a fan of this since size depends on the
cursor theme.

Has anyone thoughts about all of this?

[1]: https://github.com/swaywm/wlroots/pull/1294
[2]: https://gitlab.freedesktop.org/wayland/weston/merge_requests/33

[Michael Arnold]

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

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

> ...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. If the application wants to load its own mouse pointer, it can do
that, possibly with the toolkit's help, if available.

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

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.

On Wed, Oct 10, 2018 at 4:17 PM Simon Ser <***@emersion.fr> wrote:

> Hi,
>
> On Tuesday, October 9, 2018 3:34 PM, Michael Arnold <***@gmail.com>
> wrote:
> > Hi,
> >
> > I'm new here and out my depth - normally I tinker together applications,
> on
> > linux, sometimes using Qt. Using Qt under Gnome/Wayland I noticed that
> the
> > mouse pointer increased in size when moved over a Qt based application.
> (The
> > defect is raised here: https://bugreports.qt.io/browse/QTBUG-70971).
> As I am
> > sure you aware, under Wayland, Qt is responsible for displaying the mouse
> > pointer and since there is no standard way across Wayland compositors to
> > determine the current cursor size, Qt sets the mouse pointer to size 32
> by
> > default. Gnome, on a none-HiDPI display (like mine), sets the mouse
> pointer
> > size to 24, hence the weird mouse pointer size change when the mouse
> pointer
> > is moved over a Qt application window where the size set to 32.
>
> Indeed, we (wlroots) have the same issue. Weston apps also choose 32, GLFW
> chooses 24 IIRC.
>
> > Understandably Johan (from Qt Co.) is reluctant to use gsettings to get
> the
> > current cursor size from within the Qt Platform Abstration Layer (QPA),
> > because that means they will need to do something similar for every
> Wayland
> > compositor and hence is suggesting (correctly from what I understand)
> that a
> > Wayland extension be created for Wayland Compositors to publish their
> mouse
> > pointer size. Qt, GTK+ etc. can then pickup the mouse pointer size
> using the
> > Wayland protocol extension and display the mouse pointer at the current
> size
> > when the mouse is over the application window.
>
> Agree. Using gsettings is not a viable solution.
>
> > But this is where I get a bit lost and would be grateful of your
> guidance:
> > from what I can see the xdg-decoration protocol got proposed and debated
> via
> > this mailing list. Is there someone on this mailing list who would be
> > interested to pickup this issue or is there some other forum where I
> need to
> > raise this request?
>
> If you want to discuss about improving the cursor situation on Wayland,
> this is
> the right place.
>
> I think we have two possible solutions: a short-term one and a long-term
> one.
>
> The short-term one is already used by Qt and some X11 apps. It uses two
> environment variables (XCURSOR_THEME and XCURSOR_SIZE) to configure the
> cursor
> theme and size. I recently had a pull request merged to always export
> those from
> the default Wayland seat's configuration in rootston, our wlroots
> compositor [1]. I just opened a Weston merge request to add support for
> this in
> Weston clients [2].
>
> The issue with that short-term solution is that in addition to cluttering
> the
> environment, it isn't multiseat aware. Let's say you have two seats (so
> you also
> have at least two cursors). Then it's difficult to tell which cursor
> belongs to
> which seat, both are identical.
>
> To fix this, a new Wayland protocol would be required. That would be the
> long-term solution. Qt and GLFW have expressed interest in such a protocol.
>
> This protocol could just tell the client which XCursor theme/size to use
> for
> which seat. Though, there are other issues with this approach: it requires
> XCursor (wouldn't work with a different cursor image specification) and
> clients
> still need to load cursors themselves (a thing the compositor usually
> already
> does). Also, some of our users want to be able to change the default cursor
> image (to e.g. use the same theme for two seats but have one with the left
> pointer image and the other with a cross image).
>
> I've thought about another proposal: a protocol that would allow clients to
> create opaque wl_buffers containing cursor images. The client would for
> instance
> ask "I want the default cursor image for seat0" and the compositor would
> create
> a wl_buffer containing it. There are still many unanswered questions
> though:
> do we expose an enum with a list of cursor images or do we allow clients
> to load
> arbitrary cursor images? How do we handle HiDPI?
>
> Alternatively, to only fix the cursor size issue without introducing a
> whole new
> protocol, Johan suggested to add a "cursor_size" event to wl_pointer in
> the core
> Wayland protocol. Pekka said he's not a fan of this since size depends on
> the
> cursor theme.
>
> Has anyone thoughts about all of this?
>
> [1]: https://github.com/swaywm/wlroots/pull/1294
> [2]: https://gitlab.freedesktop.org/wayland/weston/merge_requests/33
>
>

[Simon Ser]

On Wednesday, October 10, 2018 4:48 PM, Michael Arnold <***@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.

[Michael Arnold]

> > > 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 lost you on this one. I was thinking that the compositor would be
responsible for applying the appropriate scale to the wl_buffer associated
with each screen, so there would be no need of a separate screen scale
factor in the protocol. So both HiDPI and scale of each screen would be
addressed together by the content of the wl_buffer. The toolkit would be
responsible for choosing the wl_buffer associated with the screen that the
application is being shown on. (So I'm assuming that the toolkit /
application, knows which screen the application is currently being
displayed on).

I imagine that toolkits, in general, would be interested in knowing the
screen scale so they can show custom mouse pointers and other screen
content appropriately, but since screen scale is associated with screens
and not the mouse, is a Mouse Pointer Extension be an appropriate place to
include a screen scale factor? (i.e. touch-screen compositors would need
to support the Mouse Pointer Extension to publish the screen scale to
toolkits / applications).

On Thu, Oct 11, 2018 at 3:38 AM Simon Ser <***@emersion.fr> wrote:

> On Wednesday, October 10, 2018 4:48 PM, Michael Arnold <***@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.
>

[Simon Ser]

On Thursday, October 11, 2018 2:57 AM, Michael Arnold <***@gmail.com> wrote:
> > > > 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 lost you on this one. I was thinking that the compositor would be
> responsible for applying the appropriate scale to the wl_buffer associated
> with each screen, so there would be no need of a separate screen scale factor
> in the protocol. So both HiDPI and scale of each screen would be addressed
> together by the content of the wl_buffer. The toolkit would be responsible
> for choosing the wl_buffer associated with the screen that the application is
> being shown on. (So I'm assuming that the toolkit / application, knows which
> screen the application is currently being displayed on).
>
> I imagine that toolkits, in general, would be interested in knowing the screen
> scale so they can show custom mouse pointers and other screen content
> appropriately, but since screen scale is associated with screens and not the
> mouse, is a Mouse Pointer Extension be an appropriate place to include a
> screen scale factor? (i.e. touch-screen compositors would need to support the
> Mouse Pointer Extension to publish the screen scale to toolkits /
> applications).

A "scale" parameter in the protocol wouldn't advertise scale factors for each
screen. Rather, it would allow clients to create cursor images with a specific
scale factor.

This is how HiDPI works in Wayland:
* For each screen, the compositor broadcasts a wl_output object. This object has
a "scale" property, which indicates the scale factor of the screen.
* The clients still needs to know on which screen each surface is. For this
purpose, compositors send a wl_surface.enter(wl_output) event each time a
surface enters a wl_output (there's also a leave event).
* Now clients know on which outputs they are displayed, and also know the scale
factor of each screen. They can pick a scale factor to draw themselves
(usually the greatest scale of all of these outputs).
* They create a wl_buffer (which is just a dumb pile of pixels) with the content
they just rendered.
* They attach the wl_buffer to their surface and set the surface scale.
* They commit the surface.

The cursor image protocol would work like this:
* The client receives wl_surface.enter for each output the cursor is on.
* The client requests a cursor image with the new protocol with the greatest of
these output scales. The compositor gives a wl_buffer containing the cursor
image to the client.
* The client attaches the buffer to the cursor surface, sets the scale and
commits.

That's why we need to add a scale parameter to the protocol: the client chooses
the cursor scale.

[Simon Ser]

Hi all,

We've had a chat about cursor images on IRC yesterday. I'll try to sum up what
we said. I've published the original logs too for reference [1].

First, it's clear that a protocol is needed. As we discussed earlier, this would
allow:
* Consistent cursors across all clients
* Per-seat configuration
* Not cluttering the environment
* Live cursor theme changes

I originally wanted to push forward a "compositor-side cursors" approach where
the compositor loads the cursor theme and allows clients to create wl_buffers
using this loaded theme. Some people (from KDE, GLFW if I recall correctly) said
there's some overhead in loading cursors on the client-side (a few megabytes,
I/O when loading images) and that could be saved. I assumed most compositors
loaded cursor themes. However, it seems that this design could get in the way of
protocol adoption because some compositors may not load cursor themes at all
(and still want cursor configuration) and some compositors use a client helper
to load cursor themes (e.g. Weston). This would make it more difficult (and
maybe less effective) to implement such a protocol. Additionally, this protocol
would be more complex to implement for compositors.

In the end, Pekka and Jonas said we should have two protocols: a simple one used
to configure xcursor (basically just sending the theme name and size to the
client) and maybe a more complicated one (creating wl_buffers). The former would
be easy to implement for all compositors while the latter could be implemented
by a subset of compositors willing to support it.

We also discussed how the new protocol should integrate with libwayland-cursor.
It would be nice to have libwayland-cursor automatically use the new protocol if
available. Currently the API looks like this:

theme = wl_cursor_theme_load(theme_name, size, shm);
cursor = wl_cursor_theme_get_cursor(theme, cursor_name);
buffer = wl_cursor_image_get_buffer(cursor->images[frame_num])

It's clear that this API is not suitable for this new protocol. We'd like to
extend it to allow the xcursor configuration protocol to be used, and if
possible allow in the future a compositor-side cursor extension to be used. This
could roughly look like something like this:

manager = wl_cursor_manager_create(display, seat, scale, default_theme_name,
default_theme_size)
buffer = wl_cursor_manager_get_cursor(manager, cursor_name, frame_num)

(This is just a draft -- all of this still needs to be discussed and is
incomplete)

I think that's about it. Please reply to this email if you think I forgot
something, got something wrong or if something's unclear.

I plan to work on a protocol proposal, and then on a libwayland-cursor API
extension. Let me know if you're interested in helping out!

Simon

[1]: https://sr.ht/Pz-j.txt

[Johan Helsing]

Hi Simon,

Sorry for not participating more activively in the discussion. Your summary
makes sense to me.

> Some people (from KDE, GLFW if I recall correctly) said
> there's some overhead in loading cursors on the client-side (a few megabytes,
> I/O when loading images) and that could be saved.

Here at Qt, we got a bug report about suspiciously high memory consumption for
very simple clients. As it turned out, over 8 MB was used per client just for
the cursor theme. Multiple scale factors, animated cursors etc. add up to quite
a bit. For some embedded setups with lots of clients, this is a problem.

This is easily solved by using a more light-weight cursor theme, but anyways; it
would be nice if there was one less pitfall.

Judging from the discussion on IRC and your API drafts, it seems like you're
already taking care of this, but I would be very happy if changes to the
libwayland-cursor API would allow (or at least don't prevent) compositor-
provided cursor buffers transparently. i.e. solving the reduncancy problem
with minimal changes to toolkit/client code.

Johan


________________________________
From: wayland-devel <wayland-devel-***@lists.freedesktop.org> on behalf of Simon Ser <***@emersion.fr>
Sent: Friday, October 12, 2018 4:06:28 PM
To: Michael Arnold
Cc: Emmanuel Gil Peyrot; Pekka Paalanen; Jonas Ådahl; wayland-***@lists.freedesktop.org
Subject: Re: Possible Wayland Extension to publish Mouse Pointer Size

Hi all,

We've had a chat about cursor images on IRC yesterday. I'll try to sum up what
we said. I've published the original logs too for reference [1].

First, it's clear that a protocol is needed. As we discussed earlier, this would
allow:
* Consistent cursors across all clients
* Per-seat configuration
* Not cluttering the environment
* Live cursor theme changes

I originally wanted to push forward a "compositor-side cursors" approach where
the compositor loads the cursor theme and allows clients to create wl_buffers
using this loaded theme. Some people (from KDE, GLFW if I recall correctly) said
there's some overhead in loading cursors on the client-side (a few megabytes,
I/O when loading images) and that could be saved. I assumed most compositors
loaded cursor themes. However, it seems that this design could get in the way of
protocol adoption because some compositors may not load cursor themes at all
(and still want cursor configuration) and some compositors use a client helper
to load cursor themes (e.g. Weston). This would make it more difficult (and
maybe less effective) to implement such a protocol. Additionally, this protocol
would be more complex to implement for compositors.

In the end, Pekka and Jonas said we should have two protocols: a simple one used
to configure xcursor (basically just sending the theme name and size to the
client) and maybe a more complicated one (creating wl_buffers). The former would
be easy to implement for all compositors while the latter could be implemented
by a subset of compositors willing to support it.

We also discussed how the new protocol should integrate with libwayland-cursor.
It would be nice to have libwayland-cursor automatically use the new protocol if
available. Currently the API looks like this:

theme = wl_cursor_theme_load(theme_name, size, shm);
cursor = wl_cursor_theme_get_cursor(theme, cursor_name);
buffer = wl_cursor_image_get_buffer(cursor->images[frame_num])

It's clear that this API is not suitable for this new protocol. We'd like to
extend it to allow the xcursor configuration protocol to be used, and if
possible allow in the future a compositor-side cursor extension to be used. This
could roughly look like something like this:

manager = wl_cursor_manager_create(display, seat, scale, default_theme_name,
default_theme_size)
buffer = wl_cursor_manager_get_cursor(manager, cursor_name, frame_num)

(This is just a draft -- all of this still needs to be discussed and is
incomplete)

I think that's about it. Please reply to this email if you think I forgot
something, got something wrong or if something's unclear.

I plan to work on a protocol proposal, and then on a libwayland-cursor API
extension. Let me know if you're interested in helping out!

Simon

[1]: https://sr.ht/Pz-j.txt