Currently the session lock client has no 100% safe way to know when it
is safe to suspend after requesting that the session be locked.
For a suspend to be safe the compositor must have either blanked or
rendered a lock surface on all outputs before suspending. This is
because the current framebuffer on suspend appears to be saved and
displayed again after suspend, at least on my Linux system.
If a new "locked" frame for all outputs is not rendered before suspend,
an "unlocked" frame or frames will likely be briefly displayed on resume
before the lock surfaces are rendered or the screen is blanked.
To fix this, wait until a lock surface has been rendered on all outputs,
or if that times out until all outputs have been blanked, before sending
the locked event to the client.
Resolving this race on the compositor side without protocol changes
is the most effective way to avoid this potential information leak,
regardless of which session lock client is used.
Warp the cursor to the center of the focused view if the cursor is not
in the bounding box of that view already. This helps the user to keep
track of their cursor when they mostly use the keyboard and the cursor
becomes hidden most of the time, also helps trackpad/trackpoint users.
This reduces the impact of keyboard groups on the Keyboard.zig
implementation and otherwise improves consistency with patterns used
elsewhere in rivers code.
There are also two small changes to the riverctl interface:
- keyboard-group-add-keyboard is renamed to keyboard-group-add
- keyboard-group-remove is added to support removing keyboards from a
group.
Currently we don't send an enter event when a new keyboard device is
created which causes issues when switching ttys. On switching away the
keyboard device is destroyed and leave is sent. Currently on switching
back the keyboard device is re-created but no enter event is sent before
we start sending key events, which is a violation of the protocol.
Still TODO are:
- Touch support for drags
- Mapping input devices to outputs (necessary for good multi-monitor
touch support)
Co-authored-by: Daan Vanoverloop <daan@vanoverloop.xyz>
- The lifetimes of the Keyboard and Switch structs are now directly
tied to the corresponding InputDevice, which has become a field of
those structs.
- Seat capabilities are now properly updated on removing a keyboard.
These changes align with input device refactoring in upstream wlroots
which will make updating to easier 0.16.0.
Until now, Seat.setFocusRaw sent all pressed keys to the client,
including ones that should be eaten. (Try e.g. changing focus to a
nested wlroots compositor with a terminal open to easily see it.)
However, only filtering out the eaten keys is not enough; they were
eaten only once all mappings had been executed. Therefore, the original
function had to be split into one looking up mappings and another
executing them.
e.g. `riverctl map -layout 0 normal Super Y spawn foot`
When this mapping is checked against a pressed key, layout 0 will be used to translate the pressed key instead of the currently active layout.
The number denotes to an index of the layouts set with
`XKB_DEFAULT_LAYOUT`.
I thought this should be fine as river won't yield to the event loop
when Seat.deinit() is called before the wlroots seat is destroyed, but
a segfault on exit has been reported with a stack trace mentioning
wlr_seat_destroy(). Let's hope this clears that up.
Currently wlroots sends use the drag destroy event before sending the
wl_data_device.leave event to the client, which makes things a bit
awkward. My patch fixing this has been merged to wlroots master so we
can remove this when upgrading to wlroots 0.15, but until then this
workaround will fix the issue.
Currently the view destruction sequence is started as soon as a view
is unmapped. However, this is incorrect as a client may map the view
again instead of destroying it.
Instead, only start the view destruction sequence when the underlying
xdg toplevel or xwayland surface is destroyed.
Repeating mappings are created using the -repeat option to the map
command:
% riverctl map normal $mod+Mod1 K -repeat move up 10
- repeating is only supported for key press (not -release) mappings
- unlike -release, -repeat does not create distinct mappings: mapping a
key with -repeat will replace an existing bare mapping and vice-versa
Resolves#306
Currently if a view is mapped while some other view is fullscreen, it
will not be added to the focus stack, which means that if the fullscreen
view is then closed the view which was not added to the focus stack will
not be focused.
To fix this, always add views to the focus stack on map.
If using the on-output-change cursor warp option river currently crashes
when the last real output is disabled as the noop output used as a
fallback is not present in the output layout.
This code is complex and increases maintenance burden but doesn't
add any functionality, only eye-candy.
Futhermore, neither I nor any of the core contributors use it.
There may be a place in river for such eye-candy down the line, in which
case this code could be revived. Currently river is early enough in its
development that our focus should be on core functionality instead.
On output change, if the cursor is not already on the newly focused
output, it will now be warped to its center. The check is necessary,
since focusing outputs with the pointer will be implemented in
the future.
The transaction system exists to coordinate size changes of all views
in a layout in order to achieve frame perfection. Since many clients
do not need to commit a new buffer in response to a activated state
change alone, this breaks things when such a configure event is tracked
by the transaction system. Instead, simply send activated and fullscreen
configures right away but still track this state in a double-buffered
way so that e.g. border color changes based on focus are frame-perfect.
This also fixes a related issue with the transaction system where views
that did not need to commit in response to our first configure were not
rendered until their next frame.
