Setting the GLESv2 parameter GL_PACK_ALIGNMENT to 1 ensures that the
stride of the glReadPixels output matches the value computed in
`pack_stride`. Since the default value of GL_PACK_ALIGNMENT is 4, this
does not make a difference under normal use; but without this patch
the stride can be incorrect; for example, with RGB565 buffers and
screenshots of regions with odd width.
wlr_output is not well-suited to checking whether direct scan-out
is happening or not. Compositors may want to use their own external
swapchains, for instance.
Additionally, ab7eabac84 ("output: leverage
wlr_output_configure_primary_swapchain()") makes it so
output_basic_test() is called before the output swapchain is
initialized, resulting in false positives.
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3620
This allows callers to set a destination size different from the
buffer size to scale them.
The DRM backend supports this. The Wayland backend doesn't yet
(we'd need to wire up viewporter).
since wayland doesn't provide a touch id in cancel events, track what
points are active so we can cancel all of them
timestamp is also not provided - use 0 because no one's paying attention
to that anyway
Closes#3000
- Simplifies the backends
- Avoids having two ways to do the same thing: previously one could
disable a layer by either omitting it from wlr_output_state.layers,
or by passing a NULL buffer
- We can change our mind in the future: we can allow users to omit
some layers and define a meaning without breaking the API.
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4017#note_1783997
When a new client comes in and tries to create a
zwlr_gamma_control_v1 object for an output which already has one,
we were destroying the old object and early-returning. The early
return causes the new object to not be set up properly: it's not
inserted in the list and doesn't get the gamma_size event.
Fix this by destroying the new object, and leave the old object
intact, which is what was the intent I think.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3605
Instead of littering #ifdefs everywhere, move them to the dedicated
attempt_XXX_backend() functions. This makes the logic in
wlr_backend_autocreate() more readable, and provides better error
messages when the X11/Wayland backends are disabled at compile-time,
or when WLR_BACKENDS contains a backend disabled at compile-time.
When we change the required dependencies for the DRM backend,
Meson might auto-disable the backend for users missing the new
requirements. This results in confused users [1] because they don't
notice the "drm-backend: NO" line burried in the Meson logs, and
then get a black screen when starting the compositor.
Update wlr_backend_autocreate() to refuse to create a backend with
only libinput (without DRM).
Users really wanting to start their compositor with a libinput
backend and without a DRM backend can manually set WLR_BACKENDS.
[1]: https://github.com/swaywm/sway/issues/7457
Replace our current logic to setup the primary swapchain with
wlr_output_configure_primary_swapchain().
- Removes some code, reducing duplication
- Stop overwriting wlr_output.swapchain with a yet-to-be-tested
swapchain: remove the error_destroy_swapchain label.
We've had this struct for a while. It'd be useful for compositors
if they want to manage the swap chains themselves instead of being
forced to use wlr_output's. Some compositors might also want to use
a swapchain without an output.
