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.
It didn't occur to me that this is a completely valid case when a key
release event is received even though there was no press event known
to river.
(I've also just had this same crash on something else, but i don't
understand what the cause could be.)
The old eat/pass-on point of view was good when there was only the
focused client to send the key to. But where does the input method
stand? Instead, we now want to know where the key goes, treating river
and clients all equally.
Thanks to ifreund for pointing me to std.BoundedArray which simplifies
some of the logic.
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.
To see why this is needed, compare the following flows:
- user: press key 'j' with Super already pressed
- Keyboard: handle mapping, focusing next view
- Seat: send wl_keyboard.enter with keys Super and 'j'
- Keyboard: eat key 'j'
versus:
- user: press key 'j' with Super already pressed
- Keyboard: eat key 'j'
- Keyboard: handle mapping, focusing next view
- Seat: send wl_keyboard.enter with key Super.
The necessity of this was already mentioned in 1e3b8ed1; however,
without a comment in code, it was removed in 393bfb42 as superfluous.
Hopefully, the newly added comment will prevent such mistakes in the
future.
Fixes https://github.com/riverwm/river/issues/978
As noticed by leon-p, last refactorings made river send a release event
to the client even if the press event has been eaten. In addition, the
introduction of input method support means that we need to remember
*why* we've eaten the key.
Also make KeycodeSet more strict: i am not aware of any case when a
keyboard could have the same key pressed twice (specifically, keyboard
groups have this handled in wlroots), so make the behavior follow a
smaller set of possible scenarios.
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.
When `focus-follows-cursor` is set and the cursor moves onto an output
where no views are present on the currently visible tags, focus the
output itself instead of an individual view.
This is useful e.g. when you want to spawn a terminal on your empty
monitor or switch it to a different tag. Previously such changes would
happen to the monitor on which you previous focus was, despite the
cursor being somewhere else.
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.
Previously new keyboards would not be added to already existing
keyboard groups on (re-)connect. Only during the creation of
the groups themselves were devices added to them. This meant
that only keyboards connected during startup - before the init
is executed - would work with groups in a typical river session.
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.
This commit adds a fullscreen rule for configuring
whether the view should be drawn fullscreen on start up.
The actions "fullscreen" and "no-fullscreen" map to the two
possible state of a view and semantically operate on the same
rule list. The behavior of adding, deleting and listing rules
follows that of float and ssd.
This commit adds position and dimensions rules for configuring
the initial position and dimensions of views.
When a view is not matched by any position rules, it is centered
in the avaliable output space matching the current behavior. If
the provided position rule places the view outside of the output,
the view's position is clamped to the output bounds (with respect
to borders).
When a view is not matched by any dimensions rules, no default
dimensions is set by the server. If the provided dimensions rule
exceeds the minimum or maximum width/height constraints of the view,
the view's width/height is clamped to the constraints.
Position and dimensions rules have no effect if a view is started
fullscreen or is not floating. A view must be matched by a float
rule in order for them to take effect.
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.
Previous order was (action, conditions, action argument), current is
(conditions, action, action argument). The old one was an expansion of
(action, conditions), which itself most likely came from the separate
<action>-filter-add commands. On the other hand, the new order keeps
action and its argument together and is in line with the logical flow
(check conditions, apply action).
On shell completions: only bash absolutely needed to be updated. fish
and zsh slightly misbehave regardless of the order.
This goes as close as possible to the behavior before this state was
introduced (keeping the improvement which needed it, 931405ab), fixing
various mis-interactions of keyboard and focus_follows_cursor focus
changes.
The following text is irrelevant to restoring correct basic FFC behavior
and talks about less common scenarios with regards to FFC clashing with
views' input region beyond their geometry, continuing the work done in
931405ab.
Scenario 1: the cursor traveling along a view's border in a "dead zone",
never initiating a focus change. If the focused view has an extended
input region, that area has some functionality (such as client-initiated
resizing); therefore it should be respected and even if another view's
geometry is also under the cursor, focus shouldn't change. In case of
unfocused views, it is a matter of consistency with the focused-view
case. This outcome is also easier to implement, as it doesn't require
any additional code.
Scenario 2: *clicking* such a dead zone, i.e. extended input region (of
an unfocused view). In question is not whether to focus the view (yes),
but whether the focus_follows_cursor_target should be set to the view as
well. Only one case seems relevant to me here, which is when ffc_target
is another view whose geometry is under the cursor, but covered by this
newly-focused view's input region. The most likely action following the
click is resizing the newly-focused view, where a touchpad or faulty
mouse could make the cursor move a bit farther after the button has been
released. I believe that ffc_target shouldn't have been updated, in
order to now prevent focus from skipping away.
(Another variant is me, wondering why the wrong view got focused and
trying to focus the right one using FFC. In that case, however, one
could ask if it's river that misbehaves and whether the application is
really well-integrated into the user's desktop when it provides a
feature they don't desire.)
Not decreasing the counter caused a weird bug where disabling/removing
an output (curiously, it seems to apply only to last active output being
removed) would lock the user out of the session, not letting the
transaction to complete (therefore hiding all views on a newly added
output) and messing up focus.
Fixes https://github.com/riverwm/river/issues/830
As discussed with ifreund on irc. This avoids extra allocation in case
of all_outputs and confusion in case of active_outputs (because with the
Output embedded in the Node, i thought its value was copied instead of
its pointer).
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.
When sending a configure, wlroots will send the same size that was sent
on the previous configure unless a new size is set. If a client resizes
their window itself, the size wlroots has in
XdgToplevel.scheduled will be obsolete and needs to be updated by river.
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.
Now with 50% less pointer warping!
The new implementation requires the user to move the cursor into the
constraint region before the constraint is activated in order to keep
behavior more predictable.
This replaces the old View.fromWlrSurface function and is more general.
This commit also moves the xdg activation request_activate listener to
Server as it has no reason to be in View.
This is more reliable since it uses absolute coordinates instead of a
relative movement which could cause the cursor position to get out of
sync with the view.
This is the same approach used for resize.
- Move the decision whether a configure should be tracked or not into
the xdg toplevel/xwayland code.
- Only track configures for xdg toplevels with the transaction system
if the dimensions of the view are affected.
Currently we may resize fullscreen views when they become visible/not
visible when switching tags even if their fullscreen state remains
constant. This is suboptimal, and as it turns out also much more complex
to implement.
We need to initialize the geometry on map to ensure the first commit is
handled correctly.
Also we don't care about the x/y of the geometry, only the width/height.
In commitTransaction() we currently the current view state to determine
whether or not to enable the view's scene tree. However we don't update
the view's current state until after that check.
