The spec for VkMemoryPropertyFlagBits says:
> device coherent accesses may be slower than equivalent accesses
> without device coherence [...] it is generally inadvisable to
> use device coherent or device uncached memory except when really
> needed
We don't really need coherent memory so let's not require it and
invalidate the memory range after mapping instead.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3868
(cherry picked from commit 52dce29e06)
The page_flip can be destroyed, but it is unconditionally accessed later
on when setting present_flags. Fix this by simply setting the
present_flags before the page_flip gets destroyed.
(cherry picked from commit 3d2f09bace)
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;
| ^~~~~
