Re: Possible Wayland Extension to publish Mouse Pointer Size
> > > 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 wrote:
> On Wednesday, October 10, 2018 4:48 PM, Michael Arnold
> 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.
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Possible Wayland Extension to publish Mouse Pointer Size
On Wednesday, October 10, 2018 4:48 PM, Michael Arnold 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.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Possible Wayland Extension to publish Mouse Pointer Size
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 wrote: > Hi, > > On Tuesday, October 9, 2018 3:34 PM, Michael Arnold > 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
Re: [PATCH wayland-protocols v2] unstable: add primary-selection protocol
Hey, Sorry, missed the ping... Just found a nit: On Sun, Sep 23, 2018 at 12:58 PM Simon Ser wrote: > From: emersion > > This primary selection is similar in spirit to the eponimous > in X11, allowing a quick "select text + middle click" shortcut > to copying and pasting. > > It's otherwise very similar to its Wayland counterpart, and > explicitly made consistent with it. > > Signed-off-by: Simon Ser > --- > > Changes from v1 to v2: renamed with the wp_ prefix > > Makefile.am | 3 +- > unstable/primary-selection/README | 4 + > .../primary-selection-unstable-v1.xml | 226 ++ > 3 files changed, 232 insertions(+), 1 deletion(-) > create mode 100644 unstable/primary-selection/README > create mode 100644 > unstable/primary-selection/primary-selection-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 6394e26..aca32c2 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -20,7 +20,8 @@ unstable_protocols = > \ > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > \ > unstable/xdg-output/xdg-output-unstable-v1.xml > \ > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > - unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > + unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > + > unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml\ > $(NULL) > > stable_protocols = > \ > diff --git a/unstable/primary-selection/README > b/unstable/primary-selection/README > new file mode 100644 > index 000..ae0a402 > --- /dev/null > +++ b/unstable/primary-selection/README > @@ -0,0 +1,4 @@ > +Primary selection protocol > + > +Maintainers: > +Simon Ser > diff --git a/unstable/primary-selection/primary-selection-unstable-v1.xml > b/unstable/primary-selection/primary-selection-unstable-v1.xml > new file mode 100644 > index 000..749dd86 > --- /dev/null > +++ b/unstable/primary-selection/primary-selection-unstable-v1.xml > @@ -0,0 +1,226 @@ > + > + > + > +Copyright © 2015, 2016 Red Hat > + > +Permission is hereby granted, free of charge, to any person obtaining > a > +copy of this software and associated documentation files (the > "Software"), > +to deal in the Software without restriction, including without > limitation > +the rights to use, copy, modify, merge, publish, distribute, > sublicense, > +and/or sell copies of the Software, and to permit persons to whom the > +Software is furnished to do so, subject to the following conditions: > + > +The above copyright notice and this permission notice (including the > next > +paragraph) shall be included in all copies or substantial portions of > the > +Software. > + > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > EXPRESS OR > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > MERCHANTABILITY, > +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT > SHALL > +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR > OTHER > +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > ARISING > +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > +DEALINGS IN THE SOFTWARE. > + > + > + > +This protocol provides the ability to have a primary selection device > to > +match that of the X server. This primary selection is a shortcut to > the > +common clipboard selection, where text just needs to be selected in > order > +to allow copying it elsewhere. The de facto way to perform this action > +is the middle mouse button, although it is not limited to this one. > + > +Clients wishing to honor primary selection should create a primary > +selection source and set it as the selection through > +wp_primary_selection_device.set_selection whenever the text selection > +changes. In order to minimize calls in pointer-driven text selection, > +it should happen only once after the operation finished. Similarly, > +a NULL source should be set when text is unselected. > + > +wp_primary_selection_offer objects are first announced through the > +wp_primary_selection_device.data_offer event. Immediately after this > event, > +the primary data offer will emit wp_primary_selection_offer.offer > events > +to let know of the mime types being offered. > + > +When the primary selection changes, the client with the keyboard focus > +will receive wp_primary_selection_device.selection events. Only the > client > +with the keyboard focus will receive such events with a non-NULL > +wp_primary_selection_offer. Across keyboard focus changes, previously > +focused clients will receive wp_primary_selection_device.events with a > +NULL wp_primary_selection_offer. > + > +In order to request the primary selection data, the client
Re: [PATCH wayland-protocols v2] unstable: add primary-selection protocol
Thanks for your review, Jonas. Carlos, what do you think of this proposal? Thanks, Simon. On Thursday, October 4, 2018 12:06 PM, Jonas Ådahl wrote: > On Sun, Sep 23, 2018 at 10:52:34AM +, Simon Ser wrote: > > > From: emersion cont...@emersion.fr > > This primary selection is similar in spirit to the eponimous > > in X11, allowing a quick "select text + middle click" shortcut > > to copying and pasting. > > It's otherwise very similar to its Wayland counterpart, and > > explicitly made consistent with it. > > Signed-off-by: Simon Ser cont...@emersion.fr > > Reviewed-by: Jonas Ådahljad...@gmail.com > > with one minor nit below. I'd prefer to get another RB or Ack (by Carlos > eg) before landing. > > > Changes from v1 to v2: renamed with the wp_ prefix > > Makefile.am | 3 +- > > unstable/primary-selection/README | 4 + > > .../primary-selection-unstable-v1.xml | 226 ++ > > 3 files changed, 232 insertions(+), 1 deletion(-) > > create mode 100644 unstable/primary-selection/README > > create mode 100644 > > unstable/primary-selection/primary-selection-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > > index 6394e26..aca32c2 100644 > > --- a/Makefile.am > > +++ b/Makefile.am > > @@ -20,7 +20,8 @@ unstable_protocols = \ > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > > \ > > unstable/xdg-output/xdg-output-unstable-v1.xml \ > > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > > > > - unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > > > > - unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > > Accidental change (tabs -> spaces) above. > > Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Possible Wayland Extension to publish Mouse Pointer Size
Hi, On Tuesday, October 9, 2018 3:34 PM, Michael Arnold 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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
