This wasn't that great:
1. Now that damage ring tracks damage across actual wlr_buffer objects,
it can use the buffer size to do any sort of cropping that needs to
happen.
2. The damage ring size really should be the size of the transformed
size of the output. Compositors currently have to call
`wlr_damage_ring_set_bounds()` where it might not be clear when to
call the function. Compositors can just check against the actual
output bounds that they care about when processing the damage.
Fixes: #3891
If this raster becomes invalid meaning that the buffer neither
has a buffer or textures. The invalidated signal will be called
to signify to its owner that it should be recreated.
Introduce properties for the main renderer and allocator the compositor
wants wlroots to use when it needs to blit to a staging buffer during
multigpu. We need to perform an additional blit if the modifier is not
compatible with the target GPU.
We need this really slow path if the user is using GPUs that don't have
common compatible modifiers. One example of a vendor that doesn't support
rendering to a LINEAR modifier (which otherwise should always exist)
is NVIDIA.
We also need to introduce allocator variants to wlr_raster_upload_texture
and wlr_raster_attach so that the given allocator can be used to
allocate a stanging buffer to aid in blitting
If the compositor is running without a renderer, that means that
the compositor must be driven by something external that may or may not
be there. So we have two scenarios:
1. This compositor is currently being watched and driven by some
external source that is consuming buffers. This is okay, because
during the commit handler `surface->current.buffer` and
`surface->buffer_damage` will be usable and things will be handled
like normal.
2. Things break however if the compositor is not currently driven. This
however is commonly temporary. Something may not be interested right now,
but later it can be. In this case we have to accumulate state until
this external consumer is ready. Here, we have to accumulate the
`buffer_damage` and keep the buffer locked until the consumer is ready.
`wlr_surface_consume` needs to be called when the state of this surface
was consumed so that it is safe to release these resources.
wlr_compositor will now wait for the current buffer to be released before
clearing relevant state. For now, this will always happen at the end of
the commit so there should be no functional change here.
Since wlr_raster supports wlr_compositor usage with and without a renderer,
use it for wlr_curosr so cursors support running on a surface without
a renderer.
The prerelease signal lets users do things things at the last moment
that would be inappropriate to do on the release signal. Inside the
prerelease signal, it is allowed to lock the buffer and also
upload/import the contents of the buffer to a texture.
If a surface with an existing buffer has a syncobj surface state created
without committing a new buffer with associated timelines, callers will
see the surface as having a syncobj state and may try to use it, but
calling the signal_release_with_buffer helper at this time will assert
on the lacking release timeline.
As this is a valid situation, remove the assert and replace it with an
early return so that callers do not need to explicitly check for the
presence of valid timelines.
Fixes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3895
A struct wlr_xdg_toplevel_configure is passed in with the whole
state. This makes it a lot clearer that the size and WM state are
always sent to the client.
