...on the basis that it reduces user-space breakage with respect to
layer-shell clients disappearing on suspend/resume and on VT change.
Revert the following two commits:
- 1edd5e2 "backend/drm: Remove reset from interface"
- 0f255b4 "backend/drm: Remove automatic reset on VT switch"
This it not intended to be reverted on the `master` branch. Instead, the
next wlroots release is anticipated to handle the situation differently,
possibly by splitting some objects and leaving output-related wl_globals
which have been announced to clients. See discussions on [issue-3944].
[issue-3944]: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3944#note_3030632
Background:
With [MR-4878] on wlroots-0.19.0, the DRM backend destroys/recreates
outputs on VT switch and in some cases on suspend/resume too. The reason
for this change was that (i) the KMS state is undefined when a VT is
switched away; and (ii) the previous outputs had issues with restoration,
particularly when the output configuration had changed whilst switched
away. This change causes two issues for users:
- Some layer-shell clients do not re-appear on output re-connection, or
may appear on a different output. Whilst this has always been the case,
it will now also happen in said situations. It is technically possible
for layer-shell clients to deal with this more thoughtfully by handling
the new-output and surface-destroy signals to achieve desired
behaviours, but such changes take time and meanwhile Desktop Environment
teams and other users consider this a serious regression.
- Some Gtk clients issue critical warnings on some compositors as they
assume that at least one output is always available. This will be fixed
in `Gtk-3.24.50` and is believed to be a harmless warning,
[MR-4878]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4878
Testing:
1. This reversion has been tested with [conky] and [GlassyClock]. With the
reversion applied, the clients remain visible after VT switching.
2. It was also tested with labwc on tty1; and sway on tty2. No adverse
affects were observed when changing output scales on either compositor.
[conky]: https://github.com/brndnmtthws/conky
[GlassyClock]: https://github.com/tsujan/GlassyClock
We store both queued and current buffers to be able to retain both the
framebuffer currently on screen and the one queued to replace it. From a
re-use perspective, we only care about the last committed framebuffer.
The viewport is only stored in order to be re-used together with the
last committed framebuffer, so do away with the queued/current
distinction and store a single viewport updated every time a commit
completes.
Instead of trying to restore the drm state when the session is activated
again, just disconnect all outputs when the session is deactivated. The
scan that triggers on session activation will rediscover the connectors.
Accessing the output state viewport require a buffer, and that might not
have a state with a buffer when preparing the plane properties for an
atomic commit.
Instead, store the properties at the same time as the fb, and use a
similar mechanism to carry the state around.
This centralizes logic common for both the atomic and libliftoff
backends. Additionally, a struct will make it easier to implement
multi-connector commits (since it can be stored in an array).
Use the same logic for cursor FBs as we currently use for primary
FBs. This also fixes the same bug as [1] but in a different, more
robust way.
The new logic integrates better with atomic and will be required
anyways in the future when set_cursor will be superseded by a better
API.
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4577
On startup, we fetch the previous MODE_ID blob ID so that
compositors can keep using the previous mode if they want to.
However, that blob doesn't belong to us, it belongs to the
previous DRM master. As a result, we get an error when trying to
destroy it.
Fix this by tracking whether the blob belongs to us or not.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3811
wlr_output.refresh is populated by core wlr_output, and thus will
be zero for a custom mode with an unset refresh rate.
Save the refresh rate from the drmModeModeInfo in wlr_drm_connector
instead.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3791
wl_display holds a lot more than wlr_session needs: wlr_session
only needs to wait for a FD to become readable, but wl_display
provides full access to the Wayland client and protocol objects.
Switch to wl_event_loop to better reflect the above.
Introduce a per-page-flip tracking struct passed to the kernel
when we request a page-flip event for an atomic commit. The kernel
will pass us back this pointer when delivering the event.
This eliminates any risk of mixing up events together. In particular,
if two events are pending, or if the CRTC of a connector is swapped,
we no longer blow up in the page-flip event handler.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3753
We can just assume CLOCK_MONOTONIC everywhere.
Simplifies the backend API, and fixes clock mismatches when multiple
backends are used together with different clocks.
The kernel complains when the damage exceeds the FB bounds:
[73850.448326] i915 0000:00:02.0: [drm:drm_atomic_check_only] [PLANE:31:plane 1A] invalid damage clip 0 0 2147483647 2147483647
Make the DRM backend behave like the Wayland one and allow compositors
to damage (0, 0, INT32_MAX, INT32_MAX) to repaint everything without
needing to know the exact buffer size.
Closes: https://github.com/swaywm/sway/issues/7632
