This reverts commit f9f90b4173.
gbm_bo_get_modifier may return a modifier in these cases:
- The kernel doesn't support modifiers but Mesa does
- WLR_DRM_NO_MODIFIERS=1 is set
However, in both of these cases, the gbm_bo has been allocated
without modifiers.
There is already a check in drm_fb_create for modifiers:
wlr_drm_format_set_has will make sure buffers with an explicit
modifier will be rejected if the DRM backend doesn't support them.
So no need for an additional check in get_fb_for_bo.
Closes: https://github.com/swaywm/wlroots/issues/2896
The previous code would always print "falling back to legacy method",
even if the format wasn't ARGB8888.
Drop get_fb_for_bo_legacy, since the code can just be inlined without
hurting readability.
Ideally we should only fallback to drmModeAddFB if the error code
indicates the BE failure, but the original PR [1] doesn't say what
error code is returned by the kernel.
[1]: https://github.com/swaywm/wlroots/pull/2569
We shouldn't strip a modifiers from buffers, because the will make
the kernel re-interpret the data as LINEAR on most drivers,
resulting in an incorrect output on screen.
PRIME support for buffer sharing has become mandatory since the renderer
rewrite. Make sure we check for the appropriate capabilities in backend,
allocator and renderer.
See also #2819.
Downgrade errors to DEBUG level, because drm_fb_create is used in
test_buffer, so errors aren't always fatal. Add ERROR logs at call
sites where a failure is fatal, to make it clear something wrong
happened.
If the import to KMS succeeds, we have a better chance to be able to
scan it out.
Importing is also necessary for test-only commits, which we want to
add in the future.
Compute only the transform matrix in the output. The projection matrix
will be calculated inside the gles2 renderer when we start rendering.
The goal is to help the pixman rendering process.
In 93cd3a79b2 ("backend/drm: stop using GBM flags"), we stopped
using the GBM_BO_USE_LINEAR flag in favor of a modifier list set
to { DRM_FORMAT_MOD_LINEAR }. However, the last argument of
drm_plane_init_surface disables modifiers -- so the buffer will just
get allocated with an implicit modifier, without necessarily being
LINEAR.
To fix this, allow modifiers when allocating the cursor buffers.
wlr_drm_plane.formats should already have the necessary LINEAR
restrictions.
Fixes: 93cd3a79b2 ("backend/drm: stop using GBM flags")
This allows a compositor to get a KMS connector object ID from a
wlr_output. The compositor can then query more information about
the connector via libdrm.
This gives more freedom to compositors and allows them to read
KMS properties that wlroots doesn't know about. For instance,
they could read the EDID or the suggested_{X,Y} properties and
change their output configuration based on that.
The subconnector property indicates the connector sub-type. This is
useful because that usually indicates what kind of connector the user
has plugged in to their monitor, e.g. a DisplayPort-to-DVI cable will
indicate a DVI subconnector. Also some laptops have non-DP connectors
that are internally linked to a DP port on the GPU.
Set the output description accordingly.
See https://drmdb.emersion.fr/properties/3233857728/subconnector
The new wlr_renderer_autocreate API is great for compositors, however
it causes some issues with DRM multi-GPU support.
A DRM child backend wants the compositor to use the parent GPU, so it
exposes the parent's DRM FD in get_drm_fd. However, in order to be able
to perform multi-GPU buffer copies, the child DRM backend still needs to
create a local renderer.
Use the new private wlr_renderer_autocreate_with_drm_fd function to
avoid creating a renderer for the parent GPU.
Fixes: e128e6c08d ("render: drop egl parameters from wlr_renderer_autocreate")
Instead of requiring callers to manually make the EGL context current
before binding a buffer and unsetting it after unbinding a buffer, do
it inside wlr_renderer_bind_buffer.
This hides renderer-specific implementation details inside the
wlr_renderer interface. Non-GLES2 renderers may not use EGL.
This removes all EGL dependencies from the backends.
References: https://github.com/swaywm/wlroots/issues/2618
References: https://github.com/swaywm/wlroots/pull/2615#issuecomment-756687006
Since 5b1b43c68c ("backend/drm: make wlr_drm_plane.{pending,queued,current}_fb
pointers"), current_fb can be NULL if there's no buffer. If current_fb
is not NULL, current_fb->wlr_buf is guaranteed to not be NULL.
Closes: https://github.com/swaywm/wlroots/issues/2634
Stop using wlr_drm_surface.{width,height} to figure out the size of a
gbm_bo. In the future we'll stop using wlr_drm_plane.surf, so these will
be zero. Instead, rely on gbm_bo_get_{width,height}.
Stop keeping track of buffers on the parent GPU when multi-GPU is used.
This removes support for export_dmabuf on secondary GPUs, but renderer
v6 will bring this back by managing the swapchains in wlr_output instead
of the backends.
wlr_drm_connector.crtc may be updated by the DRM backend while a
page-flip is pending. In this case, the page-flip handler won't be able
to find the right wlr_drm_connector from the CRTC ID.
Save the CRTC when performing a page-flip to ensure we always find the
right connector when we get the event.
When the session is inactive, we can't change the KMS state. Ignore
hotplug events so that compositors don't try to perform a modeset when
a connector is plugged in. We already re-scan connectors when the
session becomes active.
To test, run a wlroots compositor on VT 1, switch to VT 2, unplug a
connector, re-plug it, switch back to VT 1. Without this patch the
screen is black on VT 1.
References: https://github.com/swaywm/wlroots/issues/2370
This callback allowed compositors to customize the EGL config used by
the renderer. However with renderer v6 EGL configs aren't used anymore.
Instead, buffers are allocated via GBM and GL FBOs are rendered to. So
customizing the EGL config is a no-op.
We now properly mark the cursor plane's formats as linear-only, and we
now have a version of wlr_drm_format_intersect that handles the case of
linear-only formats and implicit modifiers.
We can remove the special drm_plane_init_surface flag we had for cursor
planes. This also allows us to use a non-linear layout for cursor planes
on drivers that support it.
Tested on amdgpu GFX9.
If the kernel driver doesn't support modifiers, it still expects cursor
FBs to have a LINEAR layout. See [1] for expectations for framebuffers
attached to the cursor plane.
[1]: https://patchwork.freedesktop.org/patch/408512/
Parse WLR_DRM_NO_MODIFIERS at startup. Don't parse IN_FORMATS when
WLR_DRM_NO_MODIFIERS is set, so that the legacy behaviour is better
reproduced.
When modifiers aren't supported, try the initial page-flip once only.
This was lost during the refactoring. We were previously calling
wlr_output_destroy, which destroyed the connector as well.
Fixes: 248c7787c7 ("backend/drm: refactor wlr_output destruction")
The DRM backend is a little special when it comes to wlr_outputs: the
wlr_drm_connectors are long-lived and are created even when no screen is
connected.
A wlr_drm_connector only advertises a wlr_output to the compositor when
a screen is connected. As such, most of wlr_output's state is invalid
when the connector is disconnected.
We want to stop using wlr_output state on disconnected connectors.
Introduce wlr_drm_connector.name which is always valid regardless of the
connector status to avoid reading wlr_output.name when disconnected.
Simplify and unify connector-specific logging with a new
wlr_drm_conn_log macro. This makes it easier to understand which
connector a failure is about, without having to explicitly integrate the
connector name in each log message.
The workaround is broken because drm_fb_acquire doesn't leave the EGL
context current anymore. We'll need to re-introduce it.
References: https://github.com/swaywm/wlroots/issues/2525
gbm_bo_create_with_modifiers doesn't take GBM flags, so our
wlr_gbm_allocator interface doesn't either. We were still internally
using GBM flags in the DRM backend, leading to awkward back-and-forth
conversions.
The only flag passed to drm_plane_init_surface was GBM_BO_USE_LINEAR, so
turn that into a bool to make sure other flags can't be passed in.
Move the "force linear" logic out of init_drm_surface, because the
supplied wlr_drm_format should already contain that information.
drm_fb_import_wlr may need to change the current EGL context. For
instance by calling drm_fb_clear, which calls wlr_buffer_unlock, which
may destroy a buffer if the cursor swapchain size has changed, which
calls gles2's destroy_buffer, which calls glDeleteFramebuffers.
Closes: https://github.com/swaywm/wlroots/issues/2479
This is just the vendor-agnostic define for the GBM platform. It has the
same value as EGL_PLATFORM_GBM_MESA, so should work with old drivers
that only offer the Mesa-vendored extension too.
On some platforms it's possible that the display engine supports
modifiers not supported by the render engine.
Query render formats and intersect them with plane formats to accommodate
for this.
After discussing with Pekka and Daniel on #dri-devel, we concluded [1]
that user-space shouldn't need to force-probe connectors. Force-probing
can take some time, so using drmModeGetConnectorCurrent can result in
faster start-up.
Users can manually trigger a force-probe if necessary:
echo detect | sudo tee /sys/class/drm/card0-DP-1/status
Or just by running a tool like drm_info.
A similar change has been submitted to Weston [2].
[1]: https://lists.freedesktop.org/archives/dri-devel/2020-November/287728.html
[2]: https://gitlab.freedesktop.org/wayland/weston/-/issues/437
Instead of operating on FDs in {open,close}_device, operate on
wlr_devices. This avoids the device lookup in wlr_session and allows
callers to have access to wlr_device fields.
For now, we use it to remove wlr_session_signal_add and replace it with
a more idiomatic wlr_session.events.change field. In the future, other
events will be added.
We would always return the GAMMA_LUT_SIZE property if available, and
only fall back to legacy gamma size otherwise. This leads to issues if
both are available in differs in size while we use the legacy backend.
Ensure that we only return the legacy size if we're using the legacy
backend.
Closes: https://github.com/swaywm/wlroots/issues/2429
When performing a modeset, the DRM backend will request a page-flip
event. However frame_pending wasn't set to true, so any subsequent
wlr_output_schedule_frame calls would imemdiately trigger a synthetic
frame event, asking the compositor to submit a new frame. Committing the
new frame fails with "a page-flip is already pending" error in the DRM
backend.
When an output is disabled one last pageflip will happen to disable it.
Currently this pageflip causes a frame event.
Since the output is disabled we don't want to send this frame event.
get_drm_prop_blob does not set path_len if it returns NULL. Check the
return value before path_len to avoid reading uninitialized memory.
(Granted, this doesn't change the logic at all, but it does make
Valgrind a bit happier.)
drm_connector_set_cursor wasn't checking the return value of the
drm_surface_make_current call. On failure, this results in a failed
assertion in wlr_renderer_begin (because no rendering context is
current).
The output backend API is now mostly state-less thanks to the atomic
hooks (commit and test). There is one exception though: attach_render.
This function makes the rendering context current. However sometimes the
compositor might decide not to render after attach_render (e.g. when
there's nothing new to render to the back buffer). Thus
wlr_output_rollback has been introduced to revert the pending state.
Because the output backend API is mostly state-less, the only thing
wlr_output_impl.rollback needs to do is revert the current rendering
context. Rename the function to rollback_render to make this clear. Add
a check in the common wlr_output code to only call rollback_render when
attach_buffer has been previously called.
On the long term, we'll be able to remove attach_render and
rollback_render together.
This patch fixes this failure:
01:57:16.642 [ERROR] [backend/drm/drm.c:360] Failed to page-flip output 'eDP-1': a page-flip is already pending
01:57:16.684 [ERROR] [backend/drm/drm.c:360] Failed to page-flip output 'eDP-1': a page-flip is already pending
01:57:16.684 [ERROR] [backend/drm/drm.c:732] Failed to initialize renderer on connector 'eDP-1': initial page-flip failed
01:57:16.684 [ERROR] [backend/drm/drm.c:805] Failed to initialize renderer for plane
01:57:16.684 [sway/config/output.c:423] Failed to commit output eDP-1
References: https://github.com/swaywm/sway/issues/5101
When the mode, status or buffer hasn't changed, drm_connector_commit was
a no-op. Because of this individual changes to the gamma LUT or adaptive
sync status were ignored (if committed without a buffer).
Instead, perform a commit to apply the changes.
A test commit doesn't apply the pending state.
The CRTC state will be populated again if the compositor decides to
perform a regular commit afterwards.
Previously, we only had the pending state (crtc->pending, crtc->mode and
crtc->active). This causes issues when a commit fails: the pending state
is left as-is, and the next commit may read stale data from it.
This will also cause issues when implementing test-only commits: we need
to rollback the pending CRTC state after a test-only commit.
Introduce separate pending and current CRTC states. Properly update the
current state after a commit.
retry_pageflip is now dead code, since drm_connector_start_renderer
isn't called anymore. It was previously called when enabling an output.
The name "retry_pageflip" was a little confusing because the function
retried a modeset and the timer wasn't set up while performing a simple
page-flip.
Let's just remove this altogether for now. We can discuss whether it's
worth it to bring it back. Should we only do it on failed page-flips?
Should we only do it on EBUSY?
If the atomic commit fails or is test-only, rollback
wlr_drm_crtc.{mode_id,gamma_lut} blob IDs to their previous value. This
prevents the next commits from failing or applying test-only state.
After swapping buffers, it doesn't make sense to perform more rendering
operations. Unset the context to reflect this.
This commit makes it so the context is always only current between
wlr_egl_make_current and wlr_egl_swap_buffers.
This is an alternative to [1].
[1]: https://github.com/swaywm/wlroots/pull/2212
This function can be called after wlr_egl_make_current to cleanup the
EGL context. This avoids having lingering EGL contexts that make things
work by chance.
Closes: https://github.com/swaywm/wlroots/issues/2197
We already have the logic to fallback to the legacy interface above. We
just need to avoid calling atomic_add with a zero prop ID.
Closes: https://github.com/swaywm/wlroots/issues/2187
dealloc_crtc was destroying GBM surfaces, but the cursor_enabled flag
was left as-is. When re-enabling the output, atomic_crtc_pageflip would
try enabling the cursor plane, but would fail because no framebuffer is
available.
Closes: https://github.com/swaywm/wlroots/issues/2150
When an output is enabled and modeset at the same time,
drm_connector_commit would first try to modeset then try to commit. This
won't work because both will trigger a page-flip. KMS will reject that.
Change the logic to only enable an output if no modeset has been
requested. The logic in wlr_output already checks that the user isn't
doing a modeset and disabling the output at the same time.
We have a workaround for legacy drivers that support drmModeSetCursor
without exposing a cursor plane. It doesn't work anymore now that we've
moved to a more atomic interface.
Let's just remove this workaround and fallback to software cursors.
Closes: https://github.com/swaywm/wlroots/issues/2166
conn->crtc is NULL in case the output is disabled.
However, the DRM backend will set the GAMMA_LUT property anyway. On each
commit the whole state is sent to KMS. Adding WLR_DRM_CRTC_GAMMA_LUT to
the pending state would just make the backend re-create the blob
containing the gamma LUT.
