When using direct scanout back_buffer is NULL. We'd emit a commit
event with WLR_OUTPUT_STATE_BUFFER set but with a NULL buffer field,
which is non-sensical.
Instead of checking whether the wlr_egl dependencies are available
in the GLES2 code, introduce internal_features['egl'] and check
that field.
When updating the EGL dependency list, we no longer need to update
the GLES2 logic.
wl_subsurface description states:
A sub-surface becomes mapped, when a non-NULL wl_buffer is applied and
the parent surface is mapped.
Note that this doesn't require an explicit commit, which means that a
newly created subsurface with a mapped parent and a buffer already
attached must be mapped immediately. This can happen with the following
sequence of events:
- subcompositor.get_subsurface(subsurface, surface, parent)
- surface.attach(buffer)
- surface.commit()
- subsurface.destroy()
- subcompositor.get_subsurface(subsurface, surface, parent)
Fixes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3449
The previous wlr_output_cursor_set_image() allows setting a NULL buffer for the
cursor to hide it. This functionality was used by sway to hide the cursor,
restore the original semantics by allowing NULL buffers again by avoiding the
wlr_buffer allocation in case we have NULL pixels and handing a NULL wlr_buffer
to wlr_output_cursor_set_buffer().
"max bpc" is a maximum value, the driver is free to choose a
smaller value depending on the bandwidth available.
Some faulty monitors misbehave with higher bpc values. We'll add
a workaround if users get hit by these in practice.
References: https://gitlab.freedesktop.org/wayland/weston/-/issues/612
Whether a texture is opaque or not doesn't depend on the renderer
at all, it just depends on the source buffer. Instead of forcing
all renderers to implement wlr_texture_impl.is_opaque, let's move
this in common code and use the wlr_buffer format to know whether
a texture will be opaque.
`vulkan_format_props_query` calls `query_modifier_support` which
initializes fields of `props` with allocated memory. this memory is
leaked if `query_modifier_support` does not find a supported format
and shmtex is not supported, as in this case `add_fmt_props` ends
up being false and the allocated fields of `props` are never freed.
...in wlr_scene_layer_surface_v1_configure()
Reproduce bug with waybar by setting `"margin": 5,`
in ~/.config/waybar/config. It will result in the right edge of the panel
extending outside the edge of the output.
The bug can also be reproduced with gtk-layer-demo by anchoring
left/right/top/bottom and setting respective margins
Relates-to: https://github.com/labwc/labwc/issues/382
Before calling wlr_output_impl.{test,commit}, perform a cheap
comparison between the current and candidate state. Unset any
fields which didn't change.
If the display is destroyed before wlr_global_destroy_safe's timer
fires, the struct destroy_global_data is leaked. This shouldn't cause
issues in practice because the timer will never fire, but makes it
harder to spot compositor memory leaks.
This refactors output_ensure_buffer() to not mutate the state passed,
making the previous subtle behavior much more explicit.
Fixes: d483dd2f ("output: add wlr_output_commit_state")
Closes: #3442
The EDID 1.4 spec says that the serial number is optional:
> If this field is not used, then enter “00h, 00h, 00h, 00h”.
Leave the wlr_output.serial field NULL in that case, and hide it
from the output description.
CTA-861-G says that "graphics" is used to indicate non-analog (ie,
digital) content. With that bit set, the sink should turn off analog
reconstruction and other related filtering.
Replace them with wlr_signal_emit_safe, which correctly handles
cases where a listener removes another listener.
Reported-by: Isaac Freund <ifreund@ifreund.xyz>
Some output commits (changing e.g. the output scale or transform)
don't require any change in the KMS state. Instead of going through
a KMS commit, return early. Blocking KMS commits can be expensive.
The wlr_output API requires compositors to wait for wlr_output.frame
before submitting a new buffer. However, compositors can perform a
commit which doesn't involve a buffer anytime.
If the commit is a modeset, we set DRM_MODE_ATOMIC_ALLOW_MODESET and
block until the commit is done. If it isn't, we currently always
perform a non-blocking commit. This is an issue because a previous
page-flip might still be in flight kernel-side, returning EBUSY.
Fix this by using blocking commits when a buffer isn't submitted by
the compositor.
Closes: https://github.com/swaywm/sway/issues/6962
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/2239
See the discussion at [1]: there's no easy way to fix libwayland-cursor
without a new API. Sending the error for other roles will prevent the
same client bug from appearing elsewhere.
[1]: https://gitlab.freedesktop.org/wayland/wayland/-/issues/194
This commit ensures that outputs that weren't created by the output
layout helper aren't destroyed on the output layout change.
Consider the following piece of logic:
// struct wlr_output *o1, *o2;
// struct wlr_scene *scene;
// struct wlr_output_layout *layout;
wlr_scene_attach_output_layout(scene, layout);
wlr_output_layout_add_auto(layout, o1);
struct wlr_scene_output *so2 = wlr_scene_output_create(scene, o2);
wlr_output_layout_move(layout, o1, 100, 200);
// so2 is invalid now
