Making these reparent() calls unconditional avoids inconsistent state.
It's also simpler and less error-prone and the wlroots function returns
immediately if the parent doesn't change anyways.
(cherry picked from commit db7de8151c)
We can end up with stale gamma settings if we don't re-check the
current gamma settings for the output on enable.
(cherry picked from commit 2e09b66963)
Currently a map-to-output input config setting loses effect when an
output is disabled and re-enabled for example.
(cherry picked from commit de3035563c)
Xwayland clients on outputs at negative positions don't currently
receive mouse events due to a bug in Xwayland. As a workaround, we
disallow negative output positions when Xwayland is enabled.
References: https://gitlab.freedesktop.org/xorg/xserver/-/issues/899Closes: #1058
Currently if we disable an output due to a wlr-output-power-management
protocol request we do not update Output.lock_render_state properly.
This is fine if the output is also re-enabled using the
wlr-output-power-management protocol but causes an assertion failure
if it is re-enabled using wlr-output-management instead.
This was dropped from 200ms to 50ms in 4a65af66. However 50ms seems
to be a bit too short in practice. I often hit ugly frame imperfection
do to timeouts when toggling mpv between a small floating window and
fullscreen for example, even on a relatively beefy desktop computer.
This only happens while the video is playing in mpv, not while it is
paused. I believe this is due to mpv ignoring the compositor's hints for
when to render a new frame entirely while playing a video. It instead
renders at the framerate of the video being played, even if the
compositor requests a change in size. This isn't great but seems
unlikely to change [1].
Overall, hitting 100ms timeouts subjectively doesn't feel anywhere near
as sluggish as hitting 200ms timeouts and offers better frame perfection
than 50ms timeouts in at least this one example, there are bound to be
others.
[1]: https://dudemanguy.github.io/blog/posts/2022-06-10-wayland-xorg/wayland-xorg.html
Sensitive Wayland protocols such as wlr_screencopy and wlr_data_control
(clipboard managment) are now blocked by default inside security
contexts (e.g. flatpak 1.15.6 or later).
User configuration of the allowlist/blocklist is TODO.
The current value of 200ms is too long and makes river feel very slow
when it it hit due to an application being very slow/frozen.
The new timeout of 50ms seems to be rarely hit in practice even on
slower hardware such as my old Thinkpad x220. When it is hit the system
feels much more responsive than when the 200ms timeout is hitdespite the
guilty application window potentially being visible in the wrong
location/size a bit longer.
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
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.
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.
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.
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.
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.
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 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.
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.
