This flag can be used to figure out whether a particular commit has
unmapped the surface. Private state for now in case we find a better
way to track this.
We can just use a regular assignment instead. This is more
type-safe since there is no need to provide the struct size.
The remaining memcpy() calls perform array copies or copies from
void pointers (which may be unaligned).
This increases type safety, makes it more obvious that role_data
must represent the role object, and will allow for automatic
cleanup when the resource is destroyed.
This commit allows to make a role as not represented by an object,
which fixes calling role commit handlers for roles like cursor
surfaces.
Fixes: 099b9de752
This is a first step towards moving texture uploading out of
wlr_compositor.
This commit allows compositors to opt-out of the texture uploading
by passing a NULL wlr_renderer. An immediate user of this is
gamescope, which currently implements a stub wlr_renderer just to
make wlr_compositor happy.
The concept of a persistent accumulated surface offset is wrong
from a protocol point-of-view. wl_surface.offset is tied to a
commit, its interpretation depends on the surface role.
For example, with the following sequence:
wl_surface@1.offset(1, 1)
wl_surface@1.commit()
wl_pointer@2.set_cursor(wl_surface@1, 42, 42)
The final cursor hotspot is (42, 42): the commit which happened
before the set_cursor request has no impact on the hotspot
computation.
The wlr_output_cursor logic already uses wlr_surface.current.{dx,dy}.
wlr_scene's drag icon doesn't, update it accordingly.
Whether a texture is opaque or not doesn't depend on the renderer
at all, it just depends on the source buffer. Instead of forcing
all renderers to implement wlr_texture_impl.is_opaque, let's move
this in common code and use the wlr_buffer format to know whether
a texture will be opaque.
See the discussion at [1]: there's no easy way to fix libwayland-cursor
without a new API. Sending the error for other roles will prevent the
same client bug from appearing elsewhere.
[1]: https://gitlab.freedesktop.org/wayland/wayland/-/issues/194
wp_viewporter protocol doesn't seem to say anything about damage, but
Firefox assumes that wp_viewport::set_source alone is enough to damage
the whole surface, and that assumption kinda makes sense, so let's do
that.