This fixes direct scanout VRR. As direct scanout buffers are not part
of the swapchain, we would mistakenly union instead of subtract the damage
meaning it will just accumulate indefinitely.
The reason for this existing in the first place is for compositors that
might want to sidestep scene and commit their own buffers to the output.
In this case, scene could theoretically acknowledge that and update the
damage. Except, this really didn't work because WLR_OUTPUT_STATE_DAMAGE
would need to be defined which is optional. This patch also properly
acknowledges commits without damage.
In the use case of a weird compositor that might want to sidestep scene,
they can just trash the damage ring themselves.
Fixes: #3871
(cherry picked from commit 14e1987f50)
There were two problems with the old implementation:
1. wlr_scene_output_commit would bail early if a frame wasn't requested
and there was no commit damage, however commit damage could never accumulate
until rendering happens. The check was subtly wrong as a result.
2. Previously, we would fill the pending commit damage based on the
current state of the damage ring. However, during direct scanout, the
damage would accumulate which would mean we would submit damage from
previous frames even if we didn't need to.
(cherry picked from commit 147c5c37e3)
Previous logic could lead wlr_wl_backend.drm_render_name being written
to twice, causing a memory leak. This commit fixes the race condition.
(cherry picked from commit 3103ea3af9)
Without this patch, a client calling handle.destroy() will trigger
an assert in libwayland due to a NULL pointer for the destroy handler.
Also implement a missing .destroy handler for the manager itself
and delay destruction of the manager resource from the .stop handler
to the .destroy handler.
(cherry picked from commit adf9d8b0be)
From the event description:
This event indicates that the output power management mode control is no
longer valid. This can happen for a number of reasons, including:
<...>
- The output disappeared
(cherry picked from commit de574ac098)
We were relying on the fact that we wouldn't paint anything on top
of the black background in the region of a black rect. However
when fractional scaling is used the repaint region might get
expanded to nearby pixels by scale_output_damage(). As a result
the neighbour scene nodes might leak into the skipped black rect's
region.
Avoid this by using this optimization for bottom-most black rects
only when fractional scaling is used.
References: https://github.com/swaywm/sway/issues/8233
../backend/drm/drm.c:415:49: error: ‘calloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args]
415 | layer->candidate_planes = calloc(sizeof(bool), drm->num_planes);
| ^~~~
../backend/drm/drm.c:1435:24: error: incompatible types when returning type ‘_Bool’ but ‘struct wlr_drm_connector *’ was expected
1435 | return false;
| ^~~~~
../render/color_lcms2.c: In function ‘wlr_color_transform_init_linear_to_icc’:
../render/color_lcms2.c:26:24: error: incompatible types when returning type ‘_Bool’ but ‘struct wlr_color_transform *’ was expected
26 | return false;
| ^~~~~
The mapping is shared between all users of the stage span, so it should
always map the whole thing and apply the allocation offset to the mapped
pointer.
The use of stage spans for 3dluts was missed when the new cached
mappings were introduced, meaning that it would try to map and unmap
memory that might already have a cached mapping.
Vulkan does not support mapping memory multiple times, so make sure the
3dlut code also uses the cached mapping to avoid segfaults after unmap.
Limiting the position to (x + width - 1, y + height - 1) created a 1px
"dead zone" at monitor edges, noticeable with high-resolution mice with
motion deltas of <1px.
See: https://github.com/swaywm/sway/issues/8110
Using (x + width - 1/65536, y + height - 1/65536) instead should make
the "dead zone" small enough to be unobservable, while the value 1/65536
is still large enough to avoid rounding to zero (due to loss of
significant digits) in simple floating-point calculations.
This does expose a client-side bug in Qt layer-shell applications,
noticeable in right/bottom panels which do not accept positions beyond
(x + width - 1, x + height - 1) as valid - thus driving the cursor
to the bottom/right of the screen to click on the panel does not work.
I don't have a good workaround for this, and probably it needs to be
fixed in Qt itself.
Fixes: 3fc66d4525
("util: fix non-linear behavior of wlr_box_closest_point()")
