We can end up with stale gamma settings if we don't re-check the
current gamma settings for the output on enable.
(cherry picked from commit 2e09b66963805caccfe8534d69f2f35dd4a4c3f7)
Currently a map-to-output input config setting loses effect when an
output is disabled and re-enabled for example.
(cherry picked from commit de3035563ccd5ea9f4fe0b843618e4265c880e30)
We must clean up the user data of the wlr_surface for layer surfaces and
lock surfaces as fromSurface() may be called (e.g. by the idle inhibit
implementation) after the scene node has been destroyed but before the
wlr_surface is destroyed.
(cherry picked from commit 28a14c6794ddc21a23d2e14d41761007d15569e8)
Official FreeBSD zig tarballs have returned!
This reverts commit 7fdba05b8249b10d10a2c64c1175429539c01af1.
(cherry picked from commit f9201ae7cdc9cf7c36817c81df0134942bfbc3cb)
There is no FreeBSD tarball from ziglang.org and FreeBSD itself has not
yet updated their Zig package to 0.12.0. This commit should be reverted
when a good way is found to obtain Zig 0.12.0 for the FreeBSD CI.
(cherry picked from commit 7fdba05b8249b10d10a2c64c1175429539c01af1)
This is a second copy of the same assert that was removed in the last
commit. It should have been removed by that commit as well but was
overlooked.
(cherry picked from commit 680cb8ef699f89cd7ce0b613221e073b534c22c5)
This assert is incorrect if Xwayland is enabled and an Override Redirect
window steals the keyboard focus from the parent surface.
It also seems likely to be hit if a Wayland client attempts to use a
pointer constraint on a subsurface. I don't think a pointer constraint
on a subsurface is likely to work entirely correctly and I don't know of
any Wayland clients that try such a thing. We can't let them crash river
by trying though.
(cherry picked from commit 5d1fc034bc6aedc340671d5de76add308effd2e8)
Currently if a second keyboard input device is created river will send
a wl_keyboard.leave event immediately followed by a wl_keyboard.enter
event. This serves no purpose and can confuse clients, in particular due
to fctix creating/destroying virtual keyboards on focus change.
Fixes: https://codeberg.org/river/river/issues/1062
References: https://github.com/fcitx/fcitx5/issues/1044
(cherry picked from commit 1e3ef88bd573e4940f7e9dcffdbf119161473e4d)
Currently if a client commits a geometry with a different x/y value but
does not change the width/height we might not update the clip
coordinates of the surface tree, potentially causing part of the surface
to be unintentionally clipped off.
To fix this, check for change in geometry x/y as well as width/height on
commit if the client is not currently part of an ongoing transaction.
Firefox for example it seems may respond to a configure non-atomically
with multiple commits:
1. commit new buffer and new geometry of a new width/height.
2. commit again with the same width/height but a new geometry x/y.
I don't think this is technically a bug but it doesn't seem like the
most efficient way to do things. I think this may also cause imperfect
frames. In any case, this should no longer cause river to crop off part
of firefox's surface.
(cherry picked from commit 9bbd34a0e31b6d429df2d39a59d8990a9585e186)
It seems layer-shell clients such as waybar can commit bogus exclusive
zones larger than the width/height of the output. While this client
behavior is questionable at best, it must not cause river to crash or
otherwise misbehave.
Therefore, close layer surfaces causing the usable (not exclusive zone)
area of an output to be reduced below half of the width/height.
Also remove the redundant URL in the footer and the redundant
"General Commands Manual" text (scdoc adds that by default based on the
section it seems).
The correct way to do this would be to use the max-width css attribute,
but codeberg seems to strip that when converting markdown to html.
The new value of 600em looks almost identical to 50% on large screens
and looks a lot better on small (mobile) screens.
Currently if we disable an output due to a wlr-output-power-management
protocol request we do not update Output.lock_render_state properly.
This is fine if the output is also re-enabled using the
wlr-output-power-management protocol but causes an assertion failure
if it is re-enabled using wlr-output-management instead.
