> > > 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 <cont...@emersion.fr> wrote:
> On Wednesday, October 10, 2018 4:48 PM, Michael Arnold <myk...@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.
>
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
