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.
This fixes an assertion in wlroots:
river: types/wlr_layer_shell_v1.c:55: layer_surface_destroy: Assertion `wl_list_empty(&surface->events.new_popup.listener_list)' failed.
