Questions about wl_pointer.set_cursor

[Pekka Paalanen]

On Tue, 17 Nov 2020 17:38:32 +0200
Alexandros Frantzis <alexandros.frantzis at collabora.com> wrote:

> Hi everyone!

Hi Alf

> 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.

> 
> 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.

Should we therefore assume that all existing clients are using the
former sequence, not the latter?

If the former sequence is "the correct one", then to avoid the race we
need to require compositors to not use the existing contents of the
wl_surface at wl_pointer.set_cursor time, basically requiring that the
latter sequence cannot work.

In any case, I think there is room for a spec clarification.

What do others think?


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20201118/976d7741/attachment.sig>