If the currently focused view has been moved to a different output but
the transaction has not yet been completed, we can hit unreachable code
in this function.
thread 1073 panic: reached unreachable code
/home/pkaplan/Software/river/river/command/view_operations.zig:100:21: 0x11752d6 in getTarget (river)
unreachable;
^
/home/pkaplan/Software/river/river/command/view_operations.zig:46:22: 0x1146f36 in focusView (river)
if (try getTarget(
^
/home/pkaplan/Software/river/river/command.zig:144:16: 0x11124e3 in run (river)
try impl_fn(seat, args, out);
^
/home/pkaplan/Software/river/river/Seat.zig:447:16: 0x10eb00f in runCommand (river)
command.run(seat, args, &out) catch |err| {
^
/home/pkaplan/Software/river/river/Seat.zig:423:24: 0x1110350 in handleMapping (river)
seat.runCommand(mapping.command_args);
^
/home/pkaplan/Software/river/river/Keyboard.zig:213:47: 0x10e83b8 in wrapper (river)
if (keyboard.device.seat.handleMapping(keycode, modifiers, released, xkb_state)) {
^
???:?:?: 0x7d8f73aa051d in ??? (libwayland-server.so.0)
Unwind information for `libwayland-server.so.0:0x7d8f73aa051d` was not available, trace may be incomplete
???:?:?: 0x7d8f739fecc7 in ??? (libwlroots-0.18.so)
???:?:?: 0x7d8f739d0dbb in ??? (libwlroots-0.18.so)
???:?:?: 0x7d8f73aa2111 in ??? (libwayland-server.so.0)
???:?:?: 0x7d8f73aa41f6 in ??? (libwayland-server.so.0)
/home/pkaplan/Software/river/river/main.zig:139:25: 0x10715dd in main (river)
server.wl_server.run();
^
/usr/lib/zig/std/start.zig:524:37: 0x107083e in main (river)
const result = root.main() catch |err| {
^
???:?:?: 0x7d8f736b06b4 in ??? (libc.so.6)
???:?:?: 0x7d8f736b0768 in ??? (libc.so.6)
???:?:?: 0x1070354 in ??? (???)
Despite the better debouncing in wlroots 0.19, this is still causing
problems. In particular, certain clients (mostly Xwayland games it
seems) have a bad interaction with this additional feedback, possibly
related to the cursor buffer.
The reported symptoms are significant framerate drops and stuttering on
pointer input.
Probably there's a wlroots bug here at fault but I don't have the
resources to fix it myself currently and would rather not force river
users to suffer.
Setting WLR_SCENE_DISABLE_DIRECT_SCANOUT=1 isn't sufficient to solve
these problems either, as wlr_scene still sends enough extra feedback
to trigger the problems.
Closes: https://codeberg.org/river/river/issues/1277
Since the Zig 0.15 upgrade, if stderr is redirected to a file, river
writes every log message to the beginning of the file, overwriting the
previous message. This commit fixes that and also switches to the nicer
new std.debug API for stderr logging.
River closes layer surfaces with an unreasonably large exclusive zone.
However, due to unfortunate/awkward code structure, this currently
may cause a use-after-free on mapping layer surface.
The wlr-virtual-keyboard-v1 protocol fails to make keyboard creation
atomic. There is nothing a client can do with a virtual keyboard that
has no keymap except for destroy it, so we can completely ignore them
until a keymap is set.
This fixes a regression with fcitx caused by river sending the null
keymap of a new virtual keyboard to fcitx.
Deprecate and ignore the riverctl commands for creating explicit
keyboard groups.
In my mind, the only reason to have more than one keyboard group is if
different keyboard devices are assigned different keymaps or repeat
rates. River does not currently allow such things to be configured
however.
When river eventually makes it possible to configure different keymaps
and repeat rates per keyboard device, there is no reason we can't 100%
automatically group keyboards based on the keymap/repeat rate.
Exposing this keyboard group abstraction to the user is just bad UX.
Failing to group keyboards automatically also creates confusing/buggy
behavior for the user if the hardware, for example, exposes some of the
the XF86 buttons on a laptop as a separate keyboard device from the main
keyboard. Creating keybindings for these XF86 buttons that use modifiers
doesn't work by default, but there's no reason it shouldn't just work.
Closes: https://codeberg.org/river/river/issues/1138
(cherry picked from commit 46f77f30dc)
If client A has an xdg_popup open and the user moves the cursor over a
surface of client B and waits for the cursor to be hidden after a
timeout, the cursor will not be shown on movement until the (invisible)
cursor is moved back into a surface of client A or somewhere the
compositor is responsible for rendering the cursor.
This is due to the (flawed) xdg popup grab interface of wlroots which
prevents wlr_seat_pointer_notify_enter() from sending events to clients
other than the one with the active xdg popup.
Closes: https://codeberg.org/river/river/issues/1192
There is now a single source of truth for river's version. It is no
longer possible for the versions in build.zig and build.zig.zon to get
out of sync as build.zig now parses the version from build.zig.zon.
This commit also tweaks the riverctl interface to make the global
allow-tearing option apply only to tearing-control-v1 hints from
clients. The global option no longer affects tearing/no-tearing rules
explicitly created by the user.
(cherry picked from commit f82b2f5816)
Making these reparent() calls unconditional avoids inconsistent state.
It's also simpler and less error-prone and the wlroots function returns
immediately if the parent doesn't change anyways.
(cherry picked from commit db7de8151c)
The assertion in PointerConstraint.confine() can currently still be
triggered if the input region of a surface is changed and the pointer is
moved outside of the new intersection of input region and constraint
region before PointerConstraint.updateState() is called.
This can happen, for example, when a client is made non-fullscreen at
the same time as the pointer is moved across the boundary of the new,
post-fullscreen, input region. If the pointer crosses the boundary
before the transaction completes and updateState() is called, the
assertion in PointerConstraint.confine() will fail.
To fix this, listen for the surface commit event rather than the
set_region event to handle possible deactivation on region changes.
(cherry picked from commit a7411ef2a6)
Currently keyboard focus is stolen from layer surfaces with
on_demand keyboard interactivity any time Root.applyPending() is called.
This commit fixes the behavior to only steal focus when explicitly
focusing a different window/layer surface.
(cherry picked from commit 4232d6b99f)
Currently we send the first configure for xdg popups before the popup
has made its initial commit. This is incorrect according to the protocol
and may confuse clients.
(cherry picked from commit ec16f1c375)
The wlroots Wayland backend does not support gamma LUT application and
will currently fail to render anything if river commits a gamma LUT.
To fix this, test the state when applying a gamma LUT and fall back to a
state with no gamma LUT set if that fails.
This problem was revealed by 2e09b66 which flags gamma as dirty on all
outputs when they are enabled.
(cherry picked from commit a80e0f7322)
The X11 protocol uses 16 bit integers for width/height but we use
32 bit integers everywhere else in river. Make sure that values outside
the range of a 16 bit integer don't cause river to crash with an
assertion failure.
I think that coordinates outside the range of a 16 bit integer could
theoretically be reasonable with tiled high resolution displays in the
future. I doubt they ever get used in practice today but at the same
time we can't allow an errant layout generator to crash river.
(cherry picked from commit ae7f4b8fcb)
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 2e09b66963)
Currently a map-to-output input config setting loses effect when an
output is disabled and re-enabled for example.
(cherry picked from commit de3035563c)
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 28a14c6794)
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 7fdba05b82)
Isaac Freund