RMFB implicitly performs a modeset to turn off any CRTC which is
using the FB. This prevents seamless transitions between two DRM
masters from working.
Use the new CLOSEFB IOCTL which doesn't turn off anything and leave
it up to the compositor to turn off outputs on shutdown if it wants
to.
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
since 4932e0d347f("backend/drm: ensure plane surfaces are cleaned up on shutdown")
at finish_drm_resources called drm_plane_finsh_surface has already free the fb
Signed-off-by: zhoulei zhoulei@kylinos.cn
Signed-off-by: sunzhguy <sunzhigang1@kylinos.cn>
Right now this is done "by chance" because we disable all CRTCs
on shutdown. However, we'll stop doing this. Plus, if disabling
a CRTC fails, we don't cleanup properly.
We can just assume CLOCK_MONOTONIC everywhere.
Simplifies the backend API, and fixes clock mismatches when multiple
backends are used together with different clocks.
We currently only perform non-blocking commits for non-modeset commits
with a buffer attached.
Perform non-blocking commits whenever there is no pending pageflip
event. If a non-blocking modeset commit fails, which can happen if the
driver implicitly added more CRTCs to the commit that we did not know we
had to wait for, retry with a blocking commit.
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/2239
The name "allow_artifacts" and associated description is very vague, and
theoretically allow for tearing behavior. Clarify that we only intend to
mean artifacts related to output configuration (e.g., modesets).
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3740
DRM_MODE_PAGE_FLIP_ASYNC doesn't allow user-space to submit new
buffers before waiting for the uevent: the kernel will return EBUSY
in that case.
Fixes: c2aa7fd965 ("backend/drm: Add async page flip support to legacy")
Since e5fc8cd4c7 ("output: trigger frame/present events on all
commits on enabled output"), any commit on an enabled output is
supposed to trigger frame/present events.
The DRM backend was skipping the commit completely for no-op
commits. Stop doing so.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3719
Up until now, frame/present events were only triggered when the
user submitted a buffer. Change the wlr_output API so that these
events are triggered when any commit is applied on an enabled
output.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3708
We were only restoring fixed modes here. The DRM backend no longer
creates fixed modes when the compositor sets a custom mode, so we
need to handle this situation when restoring.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3698
This changes the semantics of wlr_output_state. Instead of having
fields with uninitialized memory when missing from the committed
bitflag, all fields are always initialized (and maybe NULL/empty),
just like we do in wlr_surface_state. This reduces the chances of
footguns when reading a field, and removes the need to check for
the committed bitfield everywhere.
A new wlr_output_state_init() function takes care of initializing
the Pixman region.
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
Based on five calls:
wlr_render_timer_create - creates a timer which can be reused across
frames on the same renderer
wlr_renderer_begin_buffer_pass - now takes a timer so that backends can
record when the rendering starts and finishes
wlr_render_timer_get_time - should be called as late as possible so that
queries can make their way back from the GPU
wlr_render_timer_destroy - self-explanatory
The timer is exposed as an opaque `struct wlr_render_timer` so that
backends can store whatever they want in there.
Commit 90d08f8f1c changed the way
wlr_drm_format_intersect worked, including passing in a destination
format list. This breaks scenarios where the intersection doesn't
find any matching formats, since we still have a valid destination
format set. This changes it to only return true if more than one
matching format is present in the intersection list.
Add a src_box state field. Use the SRC_* KMS props in the DRM
backend, reject the layers in the Wayland backend (for now, we can
support it later via viewporter).
This allows callers to set a destination size different from the
buffer size to scale them.
The DRM backend supports this. The Wayland backend doesn't yet
(we'd need to wire up viewporter).
We've had this struct for a while. It'd be useful for compositors
if they want to manage the swap chains themselves instead of being
forced to use wlr_output's. Some compositors might also want to use
a swapchain without an output.
The hardcoded fallback "/usr/share/hwdata/pnp.ids" was only a
temporary solution to get things working while distributions were
still working on shipping it.
Since 1d581656c7 ("backend/drm: set "max bpc" to the max") we
set the "max bpc" property to the maximum value. The kernel driver
is supposed to clamp this value depending on hardware capabilities.
All kernel drivers lower the value depending on the GPU capabilities.
However, none of the drivers lower the value depending on the DP-MST
link capabilities. Thus, enabling a 4k@60Hz mode can fail on some
DP-MST setups due to the "max bpc" property.
Additionally, it's not a good idea to unconditionally set "max bpc"
to the max. A high bpc consumes more lanes and more clock speed,
which means higher power consumption and the busy lanes cannot be
used for something else (e.g. other data transfers on a USB-C cable).
For now, let's tie the "max bpc" to the pixel format of the buffer.
Introduce a heuristic to make "high bit-depth buffer" a synonym of
"I want the best quality".
This is not perfect: a "max bpc" higher than 8 might be desirable
for pixel formats with a color depth of 8 bits, for instance when
the color management KMS properties are used. But we don't really
support that yet, so let's leave this for later.
Closes: https://github.com/swaywm/sway/issues/7367
When the user switches away from the VT where wlroots is running,
the new DRM master may mutate the KMS state in an arbitrary manner.
For instance, let's say wlroots uses the following connector/CRTC
mapping:
- CRTC 42 drives connector DP-1
- CRTC 43 drives connector DP-2
Then the new DRM master may swap the mapping like so:
- CRTC 42 drives connector DP-2
- CRTC 43 drives connector DP-1
wlroots needs to restore its own state when the user switches back.
Some state is attached to wlr_drm_crtc (e.g. current FB), so reading
back and adopting the CRTC/connector mapping left by the previous DRM
master would be complicated (this was the source of other bugs in the
past, see [1]).
With the previous logic, wlroots merely tries to restore the state
of each connector one after the other. This fails in the scenario
described above: the kernel refuses to use CRTC 42 for DP-1, because
that CRTC is already in-use for DP-2.
Unfortunately with the legacy uAPI it's not possible to restore the
state in one go. We need to support both legacy and atomic uAPIs, so
let's fix the bug for the legacy uAPI first, and then improve the
situation for the atomic uAPI as a second step [2].
We need to disable the CRTCs we're going to switch the connectors for.
This sounds complicated, so let's just disable all CRTCs to simplify.
This causes a black screen because of the on/off modesets, but makes
VT switch much more reliable, so I'll take it.
[1]: c6d8a11d2c
[2]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3794
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3342
We only need it for one thing: gamma size. Moreover, some bits in
the drmModeCrtc will become out-of-date, for instance the current
mode, so let's avoid caching the whole struct and only keep what
we know won't change.
connect_drm_connector() may be called long after create_drm_connector().
During that time the DRM mode might have changed. Avoid working with
stale information.
match_obj() might return a configuration where the CRTC for an
enabled connector is switched to another one.
We don't support this correctly: the wlr_output common code would
need to query again the supported formats, re-allocate the
swapchain, etc.
What's more, the kernel doesn't even support this [1]: it
requires planes to be disabled to change their CRTC, it rejects
commits directly switching the CRTC used by a plane.
[1]: https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/drm_atomic.c?h=6e90293618ed476d6b11f82ce724efbb9e9a071b#n697
If the commit fails, then our local state becomes out-of-sync with
the kernel's. Additionally, when disabling a connector without going
through dealloc_crtc(), conn->crtc would still be set.
Fix this by updating conn->crtc in drm_connector_commit_state().
The raw enum value wasn't informative enough. It's not trivial to
tell whether 0 means connected or disconnected.
Drop the status from the state after realloc, since the exact same
information is printed right above.
Instead of having a pending_fb field on the struct wlr_drm_plane,
move it to struct wlr_drm_connector_state. That way, there's no
risk having a stale pending FB around: the state doesn't survive
across tests and commits.
The cursor is a special case because it's disconnected from the
atomic state: the wlr_backend_impl.set_cursor hook sets the cursor
for the next commit. Move the field to
wlr_drm_connector.cursor_pending_fb.
We'll move the pending primary FB into the connector state in the
next commit, dropping wlr_drm_plane.pending_fb in the process.
Introduce a dedicated field for the cursor, which has to be managed
in a special way due to our set_cursor API.
We were calling drm_connector_supports_vrr() before
drm_connector_alloc_crtc(). Thus, when an output is currently off,
the VRR test would always fail, because it checks that the
vrr_enabled CRTC prop exists.
The following situation can be dangerous:
- Output DP-1 is plugged in, compositor enables it.
- User VT switches away.
- User unplugs DP-1.
- User VT switches back.
- scan_drm_connectors() figures out the output is now disconnected,
uninitializes the struct wlr_output.
- The loop restoring previous output state in handle_session_active()
accesses the struct wlr_output to figure out what to restore.
By chance, we zero out the struct wlr_output after uninitializing it,
so enabled and current_mode will always be zero. But let's make sure
we handle this case explicitly, to remind future readers that it exists
and make the code less fragile.
The old drm_connector_set_mode() function did that by calling
drm_crtc_page_flip(). We lost this in the refactoring.
Fixes: f216e97983 ("backend/drm: drop drm_connector_set_mode()")
