<div dir="ltr"><div dir="ltr">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 (<a href="http://doc.qt.io/qt-5/qcursor.html">http://doc.qt.io/qt-5/qcursor.html</a>). 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. </div></div> <div class="gmail_quote"><div dir="ltr">On Wed, Oct 10, 2018 at 4:17 PM Simon Ser <<a href="mailto:contact@emersion.fr">contact@emersion.fr</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, On Tuesday, October 9, 2018 3:34 PM, Michael Arnold <<a href="mailto:myk321@gmail.com" target="_blank">myk321@gmail.com</a>> 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: <a href="https://bugreports.qt.io/browse/QTBUG-70971" rel="noreferrer" target="_blank">https://bugreports.qt.io/browse/QTBUG-70971</a>). 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]: <a href="https://github.com/swaywm/wlroots/pull/1294" rel="noreferrer" target="_blank">https://github.com/swaywm/wlroots/pull/1294</a> [2]: <a href="https://gitlab.freedesktop.org/wayland/weston/merge_requests/33" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/wayland/weston/merge_requests/33</a> </blockquote></div>