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.
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.
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().
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
This has been introduced way back in
be297d9d14 but is never used anywhere.
If compositors want to save the old dimensions before reacting to a
fullscreen or maximize event they can just grab the sizes within their
event handlers instead.
This change makes it possible to support both the direct srgb-format
pipeline and indirect (color-managed, or non-srgb-format) pipeline
for the same render buffer.
Instead of having separate getters for shm formats and DMA-BUF
formats, use the same pattern as wlr_output_impl.get_primary_formats
with a single function which takes buffer caps as input.
The surface argument is only used to obtain a wlr_seat_client and
semantically makes no sense. The wl_touch.cancel event applies to all
touch points and all surfaces of a client.
I decided to make the functions accept a wlr_seat_client rather than a
wl_client as it is directly available in the wlr_touch_point struct and
simplifies the implementation.
This is worth doing despite wl_client_get_destroy_listener() incorrectly
accepting a mutable wl_client pointer since this lookup_client()
function will primarily be used with a wl_display_global_filter_func_t
which only provides a const wl_client pointer.
Work around this libwayland API wart in wlroots so compositors don't
have to.
I wish to use a allowlist of globals for my security context
implementation rather than a blocklist, which means I need access to
the wp_single_pixel_buffer_manager_v1 global in order to allowlist it.
I think using a allowlist will make it harder for me to accidentally
expose globals to a security context that were meant to be restricted.
I wish to use a allowlist of globals for my security context
implementation rather than a blocklist, which means I need access to
the ext_idle_notifier_v1 global in order to allowlist it.
I think using a allowlist will make it harder for me to accidentally
expose globals to a security context that were meant to be restricted.
I wish to use a allowlist of globals for my security context
implementation rather than a blocklist, which means I need access to
the wl_shm global in order to allowlist it.
I think using a allowlist will make it harder for me to accidentally
expose globals to a security context that were meant to be restricted.
This new helper assists compositors in allocating buffers for
modesets. It degrades to different allocation parameters as
needed, and should help with screens not turning on when multiple
outputs are connected on some hardware (e.g. Intel).
For simplicity, the old logic to try allocating with explicit
modifiers first and then fallback to implicit modifiers later is
left as-is. We'll probably want to have more complicated logic
instead in the future: try the fallback on one output at a time,
and try dropping modifiers one by one instead of using implicit
modifiers (at the cost of some combinatorial explosion).
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/1873
Co-authored-by: Kenny Levinsen <kl@kl.wtf>
This centralizes logic common for both the atomic and libliftoff
backends. Additionally, a struct will make it easier to implement
multi-connector commits (since it can be stored in an array).
This allows us to remove the renderer destroy listener. The
listener was buggy: compositors can't destroy surface resources on
their own.
The wlr_compositor will always outlive the wlr_surface, so no need
for a destroy listener.
Use the same logic for cursor FBs as we currently use for primary
FBs. This also fixes the same bug as [1] but in a different, more
robust way.
The new logic integrates better with atomic and will be required
anyways in the future when set_cursor will be superseded by a better
API.
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4577
Saving the old context and immediately making our own context
current is a common pattern. Let's make it easier to do.
No functional change, just refactoring.
For XWayland surfaces that start maximized, it's best to send an initial
Configure event to set the size of the surface before mapping it. This
reduces visual glitches since the application sees the correct maximized
size when performing its initial layout and drawing.
wlroots surfaces emit their first "map" event after the XWayland window
has already been mapped and the first frame has been drawn & committed.
This is too late to send the initial Configure event.
So, add a new "map_request" event which is emitted immediately before
telling XWayland to map the window. Compositors can connect to this
event to send the initial Configure event to an XWayland app based on
its requested maximized (or fullscreen) state.
Compositors should not place anything visually on the screen at this
point but rather wait until the "map" event as before.
On startup, we fetch the previous MODE_ID blob ID so that
compositors can keep using the previous mode if they want to.
However, that blob doesn't belong to us, it belongs to the
previous DRM master. As a result, we get an error when trying to
destroy it.
Fix this by tracking whether the blob belongs to us or not.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3811
This implements the new ext-foreign-toplevel-list-v1 protocol [1].
Implemented analog to the zwlr-foreign-toplevel-management-v1 implementation.
The additional _ext_ in the names was added to avoid name collisions.
[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/187
Co-authored-by: Leon Henrik Plickat <leonhenrik.plickat@stud.uni-goettingen.de>
Compositors now are expected to wait for an initial commit by checking
wlr_xdg_surface.initial_commit on every surface commit and send
(schedule) configure events manually.
Since we only use the backend capabilities here we can simply pass
them in directly. This allows other locations to create an allocator
even if they don't have a backend. They can simply specify the caps
they want instead.
Some opaque pixel formats (nv12, p010) require per-plane bytes_per_block
info. However, it doesn't make sense to store them in
wlr_pixel_format_info, as they will never be useful (currently, this
info is used for shm, which doesn't have a concept of multi-planar
buffers.)
Let's define a separate array and function for determining whether a
pixel format has alpha.
