...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
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).
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
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
Previously, we were copying wlr_output_state on the stack and
patching it up to be guaranteed to have a proper drmModeModeInfo
stored in it (and not a custom mode). Also, we had a bunch of
helpers deriving DRM-specific information from the generic
wlr_output_state.
Copying the wlr_output_state worked fine so far, but with output
layers we'll be getting a wl_list in there. An empty wl_list stores
two pointers to itself, copying it on the stack blindly results in
infinite loops in wl_list_for_each.
To fix this, rework our DRM backend to stop copying wlr_output_state,
instead add a new struct wlr_drm_connector_state which holds both
the wlr_output_state and additional DRM-specific information.
Using GBM to import DRM dumb buffers tends to not work well. By
using GBM we're calling some driver-specific functions in Mesa.
These functions check whether Mesa can work with the buffer.
Sometimes Mesa has requirements which differ from DRM dumb buffers
and the GBM import will fail (e.g. on amdgpu).
Instead, drop GBM and use drmPrimeFDToHandle directly. But there's
a twist: BO handles are not ref'counted by the kernel and need to
be ref'counted in user-space [1]. libdrm usually performs this
bookkeeping and is used under-the-hood by Mesa.
We can't re-use libdrm for this task without using driver-specific
APIs. So let's just re-implement the ref'counting logic in wlroots.
The wlroots implementation is inspired from amdgpu's in libdrm [2].
Closes: https://github.com/swaywm/wlroots/issues/2916
[1]: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/110
[2]: 1a4c0ec9ae/amdgpu/handle_table.c
Right now callers of drm_crtc_commit need to check whether the
interface is legacy or atomic before passing the TEST_ONLY flag.
Additionally, the fallbacks for legacy are in-place in the common
code.
Add a test_only arg to the crtc_commit hook. This way, there's no
risk to pass atomic-only flags to the legacy function (add an assert
to ensure this) and all of the legacy-specific logic can be put back
into legacy.c (done in next commit).
Stop assuming that the state to be applied is in output->pending in
crtc_commit. This will allow us to remove ephemeral fields in
wlr_drm_crtc, which are used scratch fields to stash temporary
per-commit data.
GAMMA_LUT_SIZE isn't an atomic property. It can be used with the legacy
interface too. So we can unify both codepaths and remove
wlr_drm_interface.crtc_get_gamma_size.
It's no guaranteed to exist though, so we still need to keep the
fallback.
Legacy gamma lut size now uses the new legacy_crtc member of
wlr_drm_crtc. This was Previously doen using old_crtc in
wlr_drm_connector, but since this refers to the crtc that was connected to
the ouput, this could give the wrong result.
