Possible Wayland Extension to publish Mouse Pointer Size

[Simon Ser]

On Thursday, October 11, 2018 2:57 AM, Michael Arnold <myk321 at gmail.com> wrote:
> > > > 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).

A "scale" parameter in the protocol wouldn't advertise scale factors for each
screen. Rather, it would allow clients to create cursor images with a specific
scale factor.

This is how HiDPI works in Wayland:
* For each screen, the compositor broadcasts a wl_output object. This object has
  a "scale" property, which indicates the scale factor of the screen.
* The clients still needs to know on which screen each surface is. For this
  purpose, compositors send a wl_surface.enter(wl_output) event each time a
  surface enters a wl_output (there's also a leave event).
* Now clients know on which outputs they are displayed, and also know the scale
  factor of each screen. They can pick a scale factor to draw themselves
  (usually the greatest scale of all of these outputs).
* They create a wl_buffer (which is just a dumb pile of pixels) with the content
  they just rendered.
* They attach the wl_buffer to their surface and set the surface scale.
* They commit the surface.

The cursor image protocol would work like this:
* The client receives wl_surface.enter for each output the cursor is on.
* The client requests a cursor image with the new protocol with the greatest of
  these output scales. The compositor gives a wl_buffer containing the cursor
  image to the client.
* The client attaches the buffer to the cursor surface, sets the scale and
  commits.

That's why we need to add a scale parameter to the protocol: the client chooses
the cursor scale.