The output feature flag has a flaw: it's not possible to check
whether the backend supports timelines during compositor
initialization when we need to figure out whether we want to enable
the linux-drm-syncobj-v1 protocol.
Introduce a backend-wide feature flag to indicate support for
timelines to address this defect.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3904
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
Instead of calling xcb_flush() directly, wait until the FD is
writable.
Ideally we'd have a non-blocking variant instead of xcb_flush(),
but libxcb doesn't have this. Also libxcb blocks when its internal
buffer is full, but not much we can do here.
This serves as a bad example: compositors should validate serials from
events instead. Also, the current implementation segfaults if
focused_surface is NULL.
After a connector scan, new connectors might have appeared and old ones
gone away. At this point, old CRTC allocations are already gone, while
new allocations are not yet needed. Skip the call.
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
Color transform can have multiple types and these different types
want to store different metadata. We previously stored this metadata
directly on wlr_color_transform even for transforms that don't use it.
Instead, let's take the prior art from wlr_scene where each scene node
is built on a base node. Notice how wlr_color_transform_lut3d now has
a `struct wlr_color_transform base`. This is advantageous in multiple
ways:
1. We don't allocate memory for metadata that will never be used.
2. This is more type safe: Compositors can pass around a
struct wlr_color_transform_lut3d if they know they only want to use a
3d_lut.
3. This is more scalable. As we add more transform types, we don't have
to keep growing a monolithic struct.
The spec for VkMemoryPropertyFlagBits says:
> device coherent accesses may be slower than equivalent accesses
> without device coherence [...] it is generally inadvisable to
> use device coherent or device uncached memory except when really
> needed
We don't really need coherent memory so let's not require it and
invalidate the memory range after mapping instead.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3868
