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.
- Remove recommendation of XKB_* environment variables in river(1) as we
now have a dedicated riverctl keyboard-layout command.
- Give an example of how to use and switch between multiple layouts in
the riverctl(1) man page.
This also cleans up the code by using @Type(), eliminating the need
for the argFlag() and boolFlag() functions.
Allowing [:0]const u8 arguments makes this parser useful for
river-control commands as well.
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.
There have been multiple "bug reports" from users that have added more
configuration using riverctl after this line starting rivertile and were
confused why that configuration has no effect.
It's not our job to explain how POSIX shell works, but we can make the
example a bit more foolproof for those who do not yet have experience
with it
This doesn't really seem worth keeping as glibc linux is already covered
by the Arch Linux CI and Void lags behind on package updates enough
compared to the others to be annoying.
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.
The fact that this call is missing is a bug, as the changes made by
arranging the output layers as well as changes to the focus will not be
fully applied.
It is not guaranteed that the next layout_demand event after a user_command
event has the same active tags (for example when there are no views visible).
As an example, a user could trigger a user_command while no views are visible,
then switch to a different tag set which has active views. The active tags of
the previous layout_demand may also be different.
Therefore it is impossible to correctly implement a layout generator which has
user commands apply only to the currently active tag set, which is solved by
this patch.
When river or wlroots write to a closed socket it could generate SIGPIPE
causing the whole desktop to seemingly "crash" with no error log of any
kind. So we ignore the SIGPIPE and just let the write fail with EPIPE to
be handled normally.
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.
In cases like multiple hi-res monitors connected through a USB dock, the
preferred mode can fail to work. Such an output was then ignored by river,
which made it impossible to even set another mode manually.
Sway has been reported to solve this issue, so let's employ their solution
and fall back to another mode if possible.
This fixes the return type of Foo.fromWlrSurface() functions which can
in fact return null in the edge case that the role matches but the
corresponding object has already been destroyed.
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>
