| Age | Commit message (Collapse) | Author |
|---|
|
This allows compositors to get back the raw drmModeModeInfo and
look at DRM-specific fields and flags.
|
|
Now it takes a reference to a destination format
|
|
|
|
Helps figuring out why e.g. get_primary_formats fails.
|
|
|
|
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.
|
|
No need to store this info in struct wlr_drm_layer. We can just
extract the size when we need it.
|
|
|
|
|
|
|
|
|
|
Since 1d581656c756 ("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
|
|
We already do it for get_drm_plane_props().
|
|
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.
|
|
|
|
If the kernel adds new enum entries for subpixel, don't read past
the end of the subpixel_map array.
|
|
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
|
|
This list contains wlr_drm_connector entries, and there is no
guarantee that the wlr_output fields are initialized.
|
|
Ensure we unlock any pending cursor FB when disabling a connector.
|
|
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.
|
|
No need to manually call drm_connector_state_init() here, we can
just let drm_connector_commit_state() handle it.
|
|
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.
|
|
There's no reason why the output should be damaged here. The current
buffer doesn't need to be re-painted.
|
|
Backends no longer need to manually call wlr_output_update_enabled()
in their commit hook: wlr_output will take care of that.
|
|
It doesn't make sense to request a page-flip for a disabled output.
Fixes: 84e727daae67 ("backend/drm: request page-flip event on modeset")
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3528
|
|
Fixes: 65836ce357e4 ("backend/drm: log modesetting commits")
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3534
|
|
|
|
|
|
The old drm_connector_set_mode() function did that by calling
drm_crtc_page_flip(). We lost this in the refactoring.
Fixes: f216e979836a ("backend/drm: drop drm_connector_set_mode()")
|
|
This stuff is immutable for a given connector.
|
|
Move a bit more logic out of the big loop in scan_drm_connectors().
|
|
Once we are DRM master, the CRTC cannot be changed behind our back
except during a VT switch.
After a VT switch, we try to restore whatever KMS state we had last
programmed. Reloading the current CRTC from KMS breaks this and
can result in a modeset without a FB.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3432
|
|
Inline it in drm_connector_commit_state(). Brings us a step closer
to unifying the test code-path and the commit code-path.
|
|
The drm_connector_commit_state() call in handle_session_active()
was not resulting in any atomic commit, because it didn't match any
of the if branches: active = true, no new buffer was committed,
and adaptive sync/gamma LUT were unchanged. Thus the commit was a
no-op.
Later on, when the compositor performs regular page-flips, the
kernel would return EINVAL indicating that a modeset was needed.
Rework the logic to use a non-blocking page-flip commit if a buffer
was committed, and use a blocking commit if the connector is on or
is being disabled. The only case where we should skip the atomic
commit is when disabling (active = false) an already-disabled
connector (conn->crtc == NULL).
Note, 6936e163b514 ("backend/drm: short-circuit no-op commits")
has introduced early returns for other situations where we don't
need to perform an atomic commit (e.g. updating scale or transform
of an output).
Fixes: f216e979836a ("backend/drm: drop drm_connector_set_mode()")
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3432
|
|
Extract the logic to fetch the current mode to a separate function
to make it more readable. Stop dying in an assert when
get_drm_prop_blob() fails. Always make it so the drmModeModeInfo
pointer is allocated so that we can free() it unconditionally.
|
|
We already have disconnect_drm_connector() to handle the
CONNECTED → DISCONNECTED transition. Let's add
connect_drm_connector() to handle DISCONNECTED → CONNECTED. This
makes scan_drm_connectors() shorter and easier to follow.
No functional change, literally just moving code around.
|
|
We were using the legacy API (with a detour through drmModeEncoder)
to find out the current CRTC for a connector. Use the atomic API
when available.
Also extract the whole logic into a separate function for better
readability, and better handle errors.
|
|
Instead of casting a wlr_output_mode to wlr_drm_mode, use
wl_container_of() for slightly better type safety.
|
|
Instead of special-casing modesets, we can just cut the wrapper
and directly call drm_crtc_page_flip(). drm_connector_test() should
already have the checks previously done in drm_connector_set_mode(),
all we need to do is update enabled/mode after a successful atomic
commit.
|
|
This was leading to crash in compositors if the wanted connector had no CRTC
|
|
This field becomes stale too easily: for instance, see 6adca4089cf4
("backend/drm: don't unconditionally set desired_enabled").
Additionally, drm_connector_alloc_crtc() needs to do some weird
dance, restoring its previous value.
Instead, add a connector arg to realloc_crtcs() to indicate a new
connector we want to enable.
|
|
drm_connector_alloc_crtc() already checks this.
|
|
This has been addressed in 8795dde94eeb ("Initialize connectors
current mode to the mode used by KMS on startup.").
|
|
We were unconditonally setting desired_enabled = true for all
connected connectors. This makes realloc_crtcs() always keep a CRTC
active for these, even if the user doesn't want to enable them.
|
|
Without allow_artifacts, applying the new state will fail because
it requires ALLOW_MODESET.
Fixes VT switch and disabling CRTCs.
|
|
When starting up, the compositor might call wlr_output_set_mode()
with a mode which is already the current one. wlroots will detect
this and make the wlr_output_set_mode() call a no-op. During the
next wlr_output_commit() call, wlroots will perform an atomic
commit without the ALLOW_MODESET flag.
This is an issue, because some drivers need ALLOW_MODESET even if
the mode is the same. For instance, if the FB stride or modifier
changed, some drivers require a modeset.
Add a new flag "allow_artifacts" which is set when the compositor
calls mode-setting functions. Use this flag to figure out whether
we want to perform atomic commits with ALLOW_MODESET.
(The name "allow_artifacts" is picked because ALLOW_MODESET is a
misnomer, see [1].)
[1]: https://patchwork.freedesktop.org/patch/505107/
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3499
|
