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.frant...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel