Wayland Relative Pointer API Progress

[Bill Spitzak]

On Wed, Jul 15, 2015 at 5:09 AM, Daniel Stone <daniel at fooishbar.org> wrote:

> On 29 June 2015 at 20:22, Bill Spitzak <spitzak at gmail.com> wrote:
> > On Sun, Jun 28, 2015 at 7:32 AM, x414e54 <x414e54 at linux.com> wrote:
> >> Clients do not draw the mouse cursor, either the GPU (using hardware
> >> overlays) or the WM does.
> >
> > Yes, I want to allow clients to use this CPU/WM support. Currently the
> > client *has* to draw the cursor (and hide the hardware one) to sync it's
> > position with the drawing. If instead the client just *moves* the cursor,
> > then the cursor is actually drawn by the compositor like you say.
>
> I haven't read the vast majority of this thread, but this isn't really
> true. There's nothing special about the cursor in drawing: just hide
> the cursor, create a small subsurface with SHM buffers, and Weston
> will use the hardware cursor as it would for an actual cursor surface.
> Problem solved.
>

The problem I have with that is that it is impossible to prevent an
incorrect composite where there is either no cursor or two cursors rendered.

The wayland api could be changed so that setting a cursor image is buffered
until a matching wl_surface commit, and this could fix the entry into
pointer-lock mode. However when locked mode is lost I don't see any way to
do it, as it may be a different client setting the cursor image than the
one that would be removing the subsurface with the fake cursor in it.

This is probably not a big deal except (as far as I can tell) it can be
fixed with a trivial change to the proposed pointer-lock. The current
proposal makes the cursor stop moving (which means the client has to hide
the cursor in any conceivable usage) and adds a "set_cursor_hint" request
that is used to set the xy position the cursor will be at when pointer lock
is lost. I want "set_cursor_hint" to actually move the cursor (and possibly
rename it to remove the word "hint"). If the client does not want that it
can hide the cursor, which it has to do anyway in the current proposal.

For some reason this has degraded into a big argument about whether locking
the cursor position to the rendered graphics is good or bad. But since the
alternative of using a subsurface would also do that, it does not matter
whether that is good or bad for deciding this.

This change combined with a pointer lock that lasts the exact same time
that the implicit grab for a button down lasts would be very useful to make
a "slow scrollbar" or a 3-D trackball where the cursor sticks to the
rendered ball's surface. Reusing an api designed for games for this seems
like a good idea to reduce Wayland's api size.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150716/bc26856f/attachment.html>