This will let compositors know if changing adaptive_sync state has any
chance of working. When false, then the current state is the only
supported state, including if adaptive_sync is currently enabled as is
the case for Wayland and X11 backends.
When true, changing state might succeed, but no guarantee is made. It
just indicates that the backend does not already know it to be
impossible.
We don't need to process all events, only those that come from the host
compositor. This also avoids running user event handlers while in the
middle of committing an output.
Fixes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3857
Some DRM devices are not KMS-capable. DRM card nodes (also
known as DRM primary nodes) are created for render-only devices
as well. Let's just use "KMS" everywhere instead of "DRM" and
"DRM card".
This commit fixes the following interaction:
1) The host compositor sends a configure sequence for an output.
2) Before handling it, the guest compositor disables and immediately
re-enables the output.
3) The guest compositor tries to ack the configure event from step 1
which isn't relevant anymore after unmapping and re-initialization.
Instead, ignore all configure events after unmapping until we're sure
the host compositor has processed the unmapping.
Also see
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/108.
- Reset all variables representing an initialized xdg_toplevel's state
on unmap.
- Send an initial commit only when an output is about to be enabled.
- If an output isn't configured yet, don't commit a buffer.
If the guest compositor disabled an output and then immediately
committed another state, we would perform a commit with a null buffer,
which is against the protocol, as the host compositor expects an
initial commit with no buffer at all.
This makes it possible for GCC to print more warnings. For instance,
the docs for -Wmaybe-uninitialized state [1]:
> These warnings are only possible in optimizing compilation, because
> otherwise GCC does not keep track of the state of variables.
Other warning options have similar requirements as well.
[1]: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wmaybe-uninitialized
It's cumbersome for compositors to guard every
wlr_color_transform_ref() or wlr_color_transform_unref() call
behind a #if WLR_HAS_COLOR_MANAGEMENT. Moreover, none of the LCMS2
types are used in our public API.
Instead, always install the color.h header, and add a stub for
wlr_color_transform_init_linear_to_icc().
Match the pkg-config name in the meson.override_dependency() call.
Fixes: 4b4f76cc13 ("Version pkgconfig, headers, and library for parallel installation")
Since wlroots almost always significantly breaks API each minor release,
allowing parallel installation of wlroots helps packagers deal with
programs that require conflicting versions of wlroots.
Closes: #3786
An editorconfig's asterix section applies to the whole file tree,
including the .git folder. The Git commit message dialog is a temporary
file named .git/COMMIT_EDITMSG, which the editorconfig applies to.
To avoid having the line length of commit messages changed to 100 chars,
add a rule to specifically unset the max_line_length for the .git
folder.
If we need to apply a color transform to rendered content, we will not
be able to use direct scanout. Explicitly skip it to not accidentally
show frames lacking the color transform.
e08d52bb introduced a bug when rotating by 90 or 270 degrees and doing
non-uniform scaling (different scale factor on X and Y axes). The scale
factor was calculated as the ratio between the src box and the rotated
dst box. But scaling is applied after rotation, so the scale factor
should instead be the ratio between rotated src box and dst box.
Reverts 77006e5565. It turns out this
change really breaks the labwc drop-shadow implementation (which relies
on scaling up single-pixel-wide buffers).
After reverting this there's still something subtley wrong with scaling
pixel locations (shown by `weston-scaler -b`) but I can't see an obvious
way to make both weston-scaler and labwc drop-shadows work in the same
way with pixman and gles2. I'll have a harder look at this but in the
mean time reverting this patch seems to make things less broken on
average.
The DRM backend's set_cursor function always return true if the
buffer is NULL. If using a NULL cursor's buffer on startup, the
wlr_output_cursor will be marked as a hardware cursor. If the
cursor later gains a non-NULL buffer and the DRM backend rejects
that buffer, the cursor will remain marked as a hardware cursor,
despite the backend not displaying it as such. As a result, the
cursor will not be displayed at all. Fix this by always resetting
the hardware_cursor field in output_cursor_attempt_hardware().
Even if the backend advertises dri3 support, querying the DRM FD may fail.
Instead of returning early, the backend creation process must continue because
shm might be supported.
UNDEFINED when used as source layout means that the contents of
the underlying memory becomes undefined. This isn't what we want
here: we don't want to mutate the imported pixel data.
The Vulkan spec isn't really clear what the proper value should be
here, but after discussing with driver developers [1] it seems like
UNDEFINED isn't the right one. The recommendation is to use GENERAL
instead.
[1]: https://github.com/ValveSoftware/gamescope/issues/356
