Possible Wayland Extension to publish Mouse Pointer Size

[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 <contact at emersion.fr> wrote:

> Hi,
>
> On Tuesday, October 9, 2018 3:34 PM, Michael Arnold <myk321 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20181010/8ae16eb3/attachment.html>