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💯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.
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
