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
This swaps the argument order of wlr_surface_accepts_touch() and
wlr_surface_accepts_tablet_v2(), putting the wlr_surface argument first
as should be the case for functions namespaced with wlr_surface_*.
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()")
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.
Kirill Primak
BiRD
chenyongxing
Isaac Freund
Simon Ser
Bill Li
Alexander Orzechowski
Kenny Levinsen
John Lindgren
Leonardo Hernández Hernández