We can't expect all clients to support all fancy formats.
WebRTC's reference implementation doesn't support 10-bit formats
yet. More generally, clients are limited by the libraries they
use: for instance, Pixman doesn't implement all OpenGL/Vulkan
formats.
Another MR [1] suggests advertising all render formats. This is a
bit heavy-handed because:
- Upgrading a 8-bit buffer to a 10-bit buffer doesn't make a lot
of sense. I don't think the compositor should expose arbitrary
pixel format conversions.
- The protocol has no preference order. Clients generally pick the
first format they receive and support.
As an alternative, only advertise two fallback formats, ARGB8888
and XRGB8888. These two are already hard-required by wl_shm and
all clients should be able to handle them.
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/5019
This reports the output properties according to the current image description.
Firefox needs this to report HDR support to documents, at least.
v2: Move abort() calls out of switch to eliminate default case. Rename
functions so they don't use a wlr_ prefix like public functions do.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
During suspend, we first disable output and then remove the input device.
This causes cursor->state->surface released while cursor->texture leaves.
Which leads to use-after-free after resume.
Add wlr-internal enums for the properties specified in
color-representation-v1 (encoding, range, chroma siting, alpha mode) so
that other parts of wlroots can use these without depending on the
protocol specifics and without needing to include the protocol headers.
Also add conversion functions to convert the protocol enum values into
the wlroots enum values.
We cache whether buffers are single-pixel buffers (and if so what color
they are) to allow rendering optimizations. But this breaks if the
client changes out the single-pixel buffer for one with a different
color, because this updates the texture in-place instead of actually
changing the buffer.
We can fix this by blocking in-place texture updates for single pixel
buffers.
Original bug: https://codeberg.org/ifreund/waylock/issues/121
See also: !5092
Commit b4ce0d8b39 ("render/egl: accept negative DRM FD to select
software rendering") added an EXT_device_drm check to figure out
whether the user selected a device with a DRM FD or without one.
However, for KMS-only devices, Mesa will never advertise the
selected KMS node:
3f1d40d230/src/egl/main/egldevice.c (L109)
Instead, pass down a parameter to indicate whether a DRM FD was
passed in.
Fixes: b4ce0d8b39 ("render/egl: accept negative DRM FD to select software rendering")
Currently if both box_a and box_b are non-empty but do not intersect,
this function does not set dest to an empty box. This contradicts the
doc comments and is surprising for users.
