I assume that I'm not the only one who has changed/will change their
email over the years of river development, so this seems like a
reasonable thing to have.
It seems like the wlr_scene implementation of sending per-surface
feedback is a bit too spammy and can lead to resource exhaustion in
clients in at least some reported cases.
Outputs using the wlr_output_layout auto-layout feature may have their
coordinates update any time an output is added/removed to the layout or
the position of another output in the layout is set.
River currently doesn't keep the scene node coordinates of such outputs
in sync with their position in the output layout, which leads to bugs
with e.g. the cursor not working properly for such outputs.
Currently we update output-management clients based on changes in the
wlr_output_layout struct. However, this is obviously wrong on closer
inspection due to the fact that not all outputs are tracked by the
wlr_output_layout at all times. I think this aproach was originally
cargo-culted from some other output-management implementation and it
needs to go.
Luckily, the solution is quite simple since the only way to configure
outputs using river is through the wlr-output-management protocol. This
means we need to send a new configuration to the output-management
client in 3 cases:
1. An output is created
2. An output is destroyed
3. A wlr-output-management config from a client is applied
Unfortunately, clients in the wild sometimes get the
configure/ack_configure/commit sequence wrong, committing the configured
surface with a size different than the one they ack'd only to later in
separate commit adpat the surface size to that requested by the
compositor.
Improve river's handling of such buggy clients to keep river's ssd
borders and internal state consistent with whatever the clients actually
commit regardless of the correctness of the clients. Log a shame message
for such clients to make me feel better about working around their bugs.
If a view that is currently being destroyed is matched by a newly added
rule river crashes due to an assertion failure.
Fix this and add another assertion to make this precondition more
visible to the users of RuleList.match().
If there is a transaction inflight when an output is disabled then we
must call View.commitTransaction() for any views evacuated from the
disabled output to ensure transaction state remains consistent.
Root.commitTransaction() will not call View.commitTransaction()
for these evacuated views as their output is no longer around.
If a new transaction is started that calls configure() on an xdg
toplevel with a timed_out/timed_out_acked configure_state we currently
leave the configure_state untouched if no new configure is needed.
This can cause an assertion failure in View.commitTransaction() if the
xdg toplevel still hasn't acked/committed by the time the new
transaction completes.
To fix this, update the configure_state as necessary.
All of these API calls checking if the device supports a given option
and checking if the value would be changed are effectively useless.
A quick peek inside the libinput source code shows us that all of these
"setter" functions validate their arguments and return an error if they
are invalid.
Since we don't do anything with the information of whether or not a
config option has been changed or if a config option is even supported
for a given device, all these apply() functions can be simplified to a
single libinput function call.
wlroots implements this behavior with its key press tracking but
continues to forward the events to the compositor. Matching the wlroots
behavior here seems like the best way to avoid strange edge cases and
this is unlikely to ever be an annoying limit in practice.
Also take this oppurtunity to finally refactor away the hasMapping()
function in a way that doesn't sacrifice correctness even when hitting
this 32 key press limit.
Currently configure timeouts hit the "client is buggy and initiated size
change while tiled or fullscreen" code path even if the client is not in
fact buggy. This causes state to get out of sync between river and the
client, and is highly visible as the borders drawn by river no longer
align with the buffer dimensions committed by the client.
This commit fixes this by tracking acks/commits in response to
configures even after a timeout and properly integrating them with the
transaction system.
There are some cases in which a view can end up with a size/position
that places some part of it outside its output. For example, a window
with a large minimum size in a tiled layout that is placed near the
right or bottom edge of the output may extend past the output bounds.
The problem with this is that part of the view outside the output bounds
may be rendered on another output where it does not belong in a multi-
monitor setup.
To fix this, clip the surfaces of the view and the borders to the output
bounds.
Focus may not actually change here so seat.focus() may not automatically
warp the cursor. Nevertheless, a cursor warp seems to be what users
expect with `set-cursor-warp on-focus` configured, especially in
combination with focus-follows-cursor.
It's unclear if this is technically a violation of the protocol or not,
but it makes little sense to do this and many clients in the wild crash
if wl_keyboard.enter is sent before wl_keyboard.keymap.
If our current approch without xkbcommon translation does not match any
mapping on a key event attempt to match the translated keysym as well.
This makes e.g. the keypad number keys (e.g. KP_1) work intuitively as
they may require translation with numlock active.
The reason we stopped doing this in I7c02ebcbc was due to layout where
e.g. Super+Shift+Space is translated as Space with the Shift modifier
consumed, thereby conflicting with a separate mapping for Super+Space.
This should not be a issue anymore though as we now only run a maximum
of one mapping per key event and we attemt to match mappings without
xkbcommon translation before attempting with translation.
It seems to be a bit too early to drop support for this legacy protocol.
Xwayland apparently still relies on it for hardware acceleration as do
fairly recent mesa versions still in widespread use.
wlroots will now load xcursor themes at the correct scale automatically
based on the scale of the outputs where ther cursors are displayed.
Also make the error handling a bit more robust.
This code could allows the view to be focused and urgent at the
same time if the request to activate the view is received just after
the pending focus has been set but before the transaction completes.
This commit leverages the new wlr_scene helper to send custom feedback
per surface rather than using the same default feedback for every
surface. This should allow direct scanout to work more reliably with
multiple outputs for example.
wl_drm is a legacy interface superseded by the linux-dmabuf
protocol. All clients should migrate.
This commit drops support for the protocol which should help find
whatever problematic clients are left in the wild.
If it turns out that this is too soon we can easily keep supporting
wl_drm for a little while longer as wlroots has not yet dropped support
for it.
The protocol states that we must send enter and leave to all text input
objects if the client has created multiple.
Only one text input is allowed to be activated by the client per seat
however.
Currently wlr-output-management config application is broken since the
pre 0.17 code relied on the (now removed) output enable/disable event to
be emitted as part of the state application.
The old code was pretty smelly and hard to understand, I'm glad the
upstream improvements pushed river's code in this directions.
Thanks to tiosgz for prompting me to look at this more closely.
There doesn't seem to be any compelling reason to use the
wlr_scene_output_layout helper, it's simpler to just make the two
necessary SceneOutput.setPosition() calls manually. This will hopefully
be refactored down to a single call eventually as well.
This logic that looked pointless to me while doing the wlroots 0.17
upgrade is in fact important as tiosgz helpfully pointed out.
It was added back in bc610c8b to address an issue. Hopefully the new
comments stop me from trying to break it again :)
The previous commit ended up clamping the accumulated f64 offset to an
integer every frame, losing any sub-pixel cursor motions. This has been
known to cause problems with high polling rate mice in the past.
Return to the same approve the move cursor mode uses to solve this and
accumulate a separate sub-pixel delta.
Currently resizing a window allows moving the invisible "internal"
cursor infinitely far off screen despite the fact that the window is
bounded by the size constraints of the client and by the output
dimensions. This means that attempting to resize past these bounds in
one dimension will result in the "internal" cursor being far out of
bounds and will require an equal movement in the opposite direction in
order to continue resizing.
Exposing this implementation detail of an invisible "internal" cursor
separate from the rendered cursor is of course bad, so clamp it to the
bounds of the resize.
Currently views which are mapped while no outputs are available can
never actually get rendered because they have 0 tags and are stuck in
the hidden stack.
This commit fixes this and they should now be restored when a new output
becomes available.
Such requests currently lead to an assertion failure.
I don't know what changed in nautilus 45.0 that caused it to start doing
this and I probably don't want to know.
This rule action accepts and assigns a set of 32 tags represented as a
32 bit integer just like all of river's other commands handling tags.
Using the singular here is potentially misleading and is also
inconsistent with set-view-tags, etc. which all use the plural.
Sorry about the breaking change for those who use master branch, ideally
I would have caught this before merging but at least I noticed before a
release.
This commit also does a bit of internal refactoring/cleanup of the rules
system.
It is possible for the assertion in PointerConstraint.confine() to fail
if a view with an active pointer constraint is, for example, resized
using a keybinding such that the pointer is outside the constraint
region.
Handle this edge case by deactivating the constraint. The other option
would be to warp the pointer to the nearest point still inside the
constraint region. Deactivating the constraint is far simpler however
and I don't expect this to be a UX pain point.
Currently river only sends the fullscreen state to a maximum of one
toplevel per output at a time and switching tags such that the
fullscreen toplevel is not visible causes the fullscreen state to be
removed.
This may be technically correct, but it causes issues when programs like
firefox trigger animations on fullscreen state change.
This commit returns river's policy here to what we did back in 0.2 and
leaves the xdg_toplevel fullscreen state set regardless of whether or
not the toplevel is currently rendered as fullscreen or if there are
other fullscreen toplevels.
This fixes possible assertion failures when quickly cancelling and
starting a new move/resize. The following steps, take from the bug
report, can currently reproduce the race:
1. Start with a window in tiled mode.
2. Begin resizing the window with your cursor.
3. Send the window back to tiled mode (with a keybind) and quickly begin
resizing it again with your cursor.
Currently if a drag icon is created but the cursor/touch point is not
moved river will render the drag icon at 0,0 instead of the cursor/touch
point location. This fixes that.
This means that interactive resize speed is no longer throttled by the
speed at which the client commits new buffers. Interactive resize speed
is now determined entirely by how fast the pointer input device is moved
by the user.
This may result in more subjectively "choppy" resizes for clients that
commit very slowly, but it should be less sluggish at least.
This was accidentally removed in 05eac54b077, which broke
SceneNodeData.fromSurface() for xdg_toplevels.
This means that thing such as xdg-activation and idle inhibit didn't
work since that commit and should work again starting from this commit.
The previous commit broke handling of keyboard interactive
layer surfaces being created on multiple outputs at once.
This new approach reverts part of the logic change in the previous
commit while keeping the fix for the crash and the new assertion.
Currently if a layer surface is focused and the user focuses a different
output the layer surface remains focused. However, updating focus on
layer surface unmap only considers seats that have the layer surface's
output focused.
To fix this there are 3 approaches I see:
1. Unfocus all layer surfaces on the old output when switching output
focus, focus any layer surfaces on the new output.
2. Disallow switching output focus while a layer surface is focused.
3. Stop caring about output focus when determining which layer surface
should gain/lose focus.
I've taken the 3rd option here as it is significantly simpler to
implement and maintain but still feels reasonably intuitive.
This eliminates cursor jitter entirely during interactive resize.
This also fixes a bug where the xdg-toplevel resizing state was not
cleared if a resize operation was aborted due to a change in view tags
or similar.
Some clients (e.g. mpv) do not respond to configures by committing
buffers of the exact size requested. Instead they may commit a buffer of
a smaller size in order to maintain an aspect ratio or not commit a
buffer at all.
Mixing views that are currently being mapped/unmapped with views that
are stashed during hotplug down to 0 outputs is error-prone and almost
certainly has a bug or two hiding currently.
If a output is removed and added back without being destroyed this must
be reinitialized.
This commit also cleans up the Root.applyPending() calls related to
output hotplug and adds some more logging.
This is a breaking change and replaces the previous
csd-filter-add/remove and float-filter-add/remove commands.
See the riverctl(1) man page for documentation on the new system.
How river currently sets this isn't really in accordance with the spirit
of the protocol. It was originally done this way to get gtk3 windows to
look a little bit better with borders drawn around them. However, I've
come to believe that river shouldn't just ignore standards like this.
The right way to do things would be to either implement the
xdg-decoration protocol for gtk properly or to be pragmatic and accept
some programs are intended to be used with CSD and that's OK.
This brings the behavior closer to what we had before the scene
graph refactor.
The main difference now is that the order has changed from background to
overlay instead of from overlay to background. This ordering seems to
make more sense in the cases I've tested and the old ordering was just
cargo-cult anyways.
Isaac Freund