Questions about wl_pointer.set_cursor

[Alexandros Frantzis]

On Wed, Nov 18, 2020 at 12:10:45PM +0200, Pekka Paalanen wrote:
> On Tue, 17 Nov 2020 17:38:32 +0200
> Alexandros Frantzis <alexandros.frantzis at collabora.com> wrote:
> 
> > Hi everyone!
> 
> Hi Alf
> 

Hi Pekka,

> > I have some questions about the expected behavior of
> > wl_pointer.set_cursor:
> > 
> > 1. Is setting the same surface as the cursor for multiple pointers allowed?
> >    I don't see anything disallowing this in the spec (but see (2)).
> >    If this is allowed, are there any useful scenarios for this?
> 
> If possible, I would like to forbid this in the protocol spec to make
> things more clear and simple.
> 
> If a client has multiple wl_seats, the pointer for each may have a
> different position, hence there is no reason to assume that the cursor
> image should be the same for them all. Therefore it's simple to just
> have a separate wl_surface for each.
> 
> If a client has multiple wl_pointer for the same wl_seat, the client
> may be fighting with itself about what the cursor image should be. It
> is not Wayland's job to referee that fight, so I see no reason to
> even consider it.
> 
> > 2. Is the cursor role for a surface specific to a particular pointer?
> >    That is, is the role == "cursor", or role == "cursor-for-pointer-X"
> >    (which would implicitly disallow reusing the surface on multiple
> >    pointers)?
> 
> Assuming we forbid using a wl_surface simultaneously on multiple
> wl_pointers, this question comes down to whether it is ok to migrate a
> wl_surface from being a cursor for one wl_pointer to another wl_pointer.
> 
> I'm not sure there is any reason to allow the migration, but I'm also
> not sure how to word the spec to that effect.

One way is for the spec to explicitly mention that the role is
"cursor-for-pointer-X" (instead of just "cursor"). This will disallow
any reuse of the surface for any other role, including as a cursor
for other pointers. Anyone who wants to migrate will need to first
unset the surface from the pointer (thus dropping any cursor role),
and set it to another pointer.

> > 
> > 3. When, after an enter event, we set a cursor surface that has a
> >    attached buffer from a previous enter, is there any requirement to
> >    recommit the buffer? It doesn't seem this is the case from the spec,
> >    but Weston doesn't like it if we don't recommit. This is likely a bug,
> >    but just making sure.
> 
> This is an interesting question, and it involves a race. Let's assume a
> client does this:
> 
> 1. wl_pointer.set_cursor(surface)
> 2. wl_surface.attach(buffer)
> 3. wl_surface.commit
> 
> If the surface already has content before step 1, but that content is
> incorrect, then if the compositor happens to repaint between steps 1
> and 3, the cursor will show incorrect for a moment. A glitch.
> 
> That glitch does not happen if the order is reversed:
> 
> 1. wl_surface.attach(buffer)
> 2. wl_surface.commit
> 3. wl_pointer.set_cursor(surface)
> 
> However, your question says that this order does not work with Weston.
> I'm not surprised, it seems a little off nowadays to give content to a
> surface before giving it a role. xdg-shell outright forbids that, for
> instance.

A clarification: both the first and second sequences you mention work
with weston, assuming no enter/leave in between. What doesn't work is
the following:

1. Enter
2. wl_surface.attach, wl_surface.commit, wl_pointer.set_cursor (order
doesn't matter for this scenario, glitches aside)
3. Leave
4. Enter
5. wl_pointer.set_cursor(surface_with_already_attached_buffer)

After (5) nothing is displayed for the cursor, where I would expect that
the cursor would use the buffer already attached during (2).

I have tried sway and gnome with an test client and they both exhibit
the expected behavior. I looked a bit more into Weston and have a
potential fix for this, if this behavior is indeed a bug.

Thanks,
Alexandros