Possible Wayland Extension to publish Mouse Pointer Size
contact at emersion.fr
Wed Oct 10 08:17:16 UTC 2018
On Tuesday, October 9, 2018 3:34 PM, Michael Arnold <myk321 at gmail.com> wrote:
> 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 . I just opened a Weston merge request to add support for this in
Weston clients .
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
Has anyone thoughts about all of this?
More information about the wayland-devel