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.
If a new buffer is set for a buffer node, we must update the entire
node unconditionally if the buffer size changes, or the buffer is given
a buffer where it was previously NULL.
While we're here, let's avoid calling scene_node_update on just damage
updates. If the caller hasn't given us a damage region we just assume
the whole buffer.
If the area calculations for output overlap overflow a signed int, we
may not consider it to be a primary output. Turn this into an unsigned
type so this happens less frequently.
Additionally, it is possible the overflow would produce 0, we can handle
this by simply changing the comparison to more than or equal.
While we're here, let's assert that we always assign a primary output
if there are any intersecting outputs.
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.
We were crashing in the error codepath [1] when
wlr_drm_create_lease() fails.
To fix this, delay the creation of the wlr_drm_lease_v1 until the
request is granted. Previously we were allocating that struct early
without populating the drm_lease field. However that means we ended
up with a half-constructed struct in the error codepath which is
annoying to handle.
[1]: https://github.com/swaywm/sway/issues/7204#issuecomment-1269797356
On first commit, require a new buffer if the compositor called a
mode-setting function, even if the mode won't change. This makes it
so the swapchain is created now.
Stop trying to check whether the backend supports buffer-less modesets
because that makes everything more complicated. For instance, the
DRM backend doesn't need a new buffer if the previous DRM master left
the output enabled.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3499
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3502
Some compositors want to have full control over the buffers attached
to the output, and don't want to use the internal swapchain. Such
compositors include KWinFT (allocates its buffers on its own) and
gamescope (uses a headless output without any buffers).
Let's just make output_ensure_buffer() a no-op in that case.
This field becomes stale too easily: for instance, see 6adca4089c
("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.
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.
In the CREATE_DUMB error code-path, we'd only free() the buffer,
however it's already inserted in the alloc->buffers list at this
point.
Instead, make sure finish_buffer() is safe to call (by populating
drm_fd) and call that function.
INVALID means that the modifier is implicit. However dumb buffers
are guaranteed to be LINEAR, so let's just advertise this. Fixes
cursors with the DRM backend: cursor planes usually only support
LINEAR.
When running with the DRM backend, the Pixman renderer needs to
render the cursor buffer. However, DRM drivers only support linear
buffers for these in general, they don't support implicit modifiers
(aka. INVALID).
Advertise support for LINEAR in the Pixman renderer to fix this.
If we have a render node, it means there is a GPU which could be
used. We probably failed GL because of a kernel or Mesa issue.
Instead of automatically falling back to Pixman, error out.
This makes it more obvious to users when something goes wrong,
instead of silently exposing a slow unaccelerated desktop.
References: https://github.com/swaywm/sway/issues/7194
