The libinput backend is now optional. However, this means that a
user building wlroots without the correct libinput dependencies
will end up with a compositor which doesn't respond to input events.
wlr_backend_autocreate is supposed to return a sensible setup, so in
this case let's just error out and explain what happened. Users can
suppress the check by setting WLR_LIBINPUT_NO_DEVICES=1 (already used
to suppress the zero input device case inside the libinput backend).
Compositors which really want to create a bare DRM backend can easily
create it manually instead of using wlr_backend_autocreate.
This patch makes it so we bind to zwp_linux_dmabuf_v1 version 4 and
we use it to grab the main device. v4 sends supported formats via a
table so we need to handle this as well.
v4 allows wlroots to remove the requirement for Mesa's internal
wl_drm interface.
wlroots picks names for all outputs, but it might be desirable for
compositor to override it.
For instance, Sway will use a headless output as a fallback in
case no outputs are connected. Sway wants to clearly label the
fallback output as such and label "real" headless outputs starting
from HEADLESS-1.
When using `meson --buildtype=release`, `-Wextra -Werror` is passed.
This includes `-Werror=maybe-uninitialized`, which complains about
the instances fixed in this commit.
drmModeAddFB2 doesn't support explicit modifiers. Only accept INVALID
which indicates an implicit modifier and LINEAR which may indicate
that GBM_BO_USE_LINEAR has been used.
The headless backend no longer needs a parent renderer: it no longer
needs to return it in wlr_backend_impl.get_renderer, nor does it
need to return its DRM FD in wlr_backend_impl.get_drm_fd. Drop this
function altogether since it now behaves exactly like
wlr_headless_backend_create.
Sometimes the headless backend is used standalone with the Pixman
renderer, sometimes it's used together with another backend which
has already picked a DRM FD. In both of these cases it doesn't make
sense to pick a DRM FD.
Broadly speaking the headless backend doesn't really care which DRM
device is used for the buffers it receives. So it doesn't really
make sense to tie it to a particular DRM device.
Let the backend users (e.g. wlr_renderer_autocreate) open an arbitrary
DRM FD as needed instead.
This field's ownership is unclear: it's in wlr_input_device, but
it's not managed by the common code, it's up to each individual
backend to use it and clean it up.
Since this is a backend implementation detail, move it to the
backend-specific structs.
There's no guarantee that the parent Wayland compositor uses
CLOCK_MONOTONIC for reporting presentation timestamps, they could
be using e.g. CLOCK_MONOTONIC_RAW or another system-specific clock.
Forward the value via wlr_backend_impl.get_presentation_clock.
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3254#note_1143061
Most (and possibly all) compositors using wlroots only ever render
fully opaque content. To provide better performance, this change
switches the default format used by wlr_output buffers from
ARGB8888 to the opaque XRGB8888.
Compositors like mutter, kwin, and weston already default to
XRGB8888, so this change is unlikely to expose any new bugs in
underlying drivers and hardware.
This does not affect the hardware cursor's buffer format, which is
still ARGB8888 by default.
As part of this change, the X11 backend (which does not support
changing format at runtime) now picks a true color, 24 bit depth
visual (i.e. XRGB8888) instead of a 32 bit depth (ARGB8888) one.
They are never used in practice, which makes all of our flag
handling effectively dead code. Also, APIs such as KMS don't
provide a good way to deal with the flags. Let's just fail the
DMA-BUF import when clients provide flags.
The BO handle table exists to avoid double-closing a BO handle,
which aren't reference-counted by the kernel. But if we can
guarantee that there is only ever a single ref for each BO handle,
then we don't need the BO handle table anymore.
This is possible if we create the handle right before the ADDFB2
IOCTL, and close the handle right after. The handles are very
short-lived and we don't need to track their lifetime.
Because of multi-planar FBs, we need to be a bit careful: some
FB planes might share the same handle. But with a small check, it's
easy to avoid double-closing the same handle (which wouldn't be a
big deal anyways).
There's one gotcha though: drmModeSetCursor2 takes a BO handle as
input. Saving the handles until drmModeSetCursor2 time would require
us to track BO handle lifetimes, so we wouldn't be able to get rid
of the BO handle table. As a workaround, use drmModeGetFB to turn the
FB ID back to a BO handle, call drmModeSetCursor2 and then immediately
close the BO handle. The overhead should be minimal since these IOCTLs
are pretty cheap.
Closes: https://github.com/swaywm/wlroots/issues/3164
Since libinput is an optional dependency the libinput backend is possibly undeclared.
wlr_backend_destroy(backend) below will clean up the child libinput backend if any.
This commit adds two error-handling cases to the function
attempt_dmr_backend. Specifically:
- In the case where the number of found GPUs is zero, we now
print a log message indicating this and return a NULL pointer
- In the case where we could not successfully create a backend
on any GPU, we now log a message indicating this and return
a NULL pointer
This allows us to provide more descriptive error messages,
as well as avoid a SEGFAULT (the function
`ensure_primary_backend_renderer_and_allocator` dereferences the pointer
given, which could be NULL until this patch) when these cases arise.
After 70fb21c35b made libinput optional the include prevents
building without libinput package installed.
backend/backend.c:4:10: fatal error: 'libinput.h' file not found
#include <libinput.h>
^~~~~~~~~~~~
drmModeAddFB2 doesn't support explicit modifiers. Only accept INVALID
which indicates an implicit modifier and LINEAR which may indicate
that GBM_BO_USE_LINEAR has been used.
Instead of ensuring the renderer and allocator are initialized in each
backend, do it in wlr_backend_autocreate. This allows compositors to
create backends without any renderer/allocator if they side-step
wlr_backend_autocreate.
Since the wlr_backend_get_renderer and backend_get_allocator end up
calling wlr_renderer_autocreate and wlr_allocator_autocreate, it sounds
like a good idea to centralize all of the opimionated bits in one place.
Expose the panel orientation with wlr_drm_connector_get_panel_orientation.
Leave it to the compositor to consume this information and configure the
output accordingly.
Closes: https://github.com/swaywm/wlroots/issues/1581
Modesets require a buffer. The DRM backend tried to auto-enable
outputs when a CRTC becomes available in the past, but now that
fails because no buffer is available.
Instead of having this magic inside the DRM backend, a better
approach is to do it in the compositor or in an optional helper.
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
The Coordinated Video Timings (CVT) spec [1] defines two types of
timings: the "CVT standard CRT" timings and the "CVT reduced blanking"
timings (see section 3.6).
The standard CRT timings include pauses in the video stream to allow
CRT displays to reposition their electron beam at the end of each
horizontal scan line [2]. While this was desirable a few decades ago,
nowadays we can just generate a CVT reduced blanking timing by default.
wlroots users can still set full custom DRM modes via
wlr_drm_connector_add_mode.
[1]: https://glenwing.github.io/docs/VESA-CVT-1.2.pdf
[2]: https://en.wikipedia.org/wiki/Coordinated_Video_Timings#Reduced_blanking
To retrieve the formats, an allocated crtc is required. If there is no
currently no crtc available, try to allocate it. This reproducable by
having a disabled output and going through a suspend cycle with amdgpu.
On start CRTCs look like this:
00:00:00.588 [DEBUG] [wlr] [backend/drm/drm.c:1099] Reallocating CRTCs
00:00:00.588 [DEBUG] [wlr] [backend/drm/drm.c:1110] State before reallocation:
00:00:00.588 [DEBUG] [wlr] [backend/drm/drm.c:1116] 'DP-1' crtc=0 state=1 desired_enabled=1
00:00:00.588 [DEBUG] [wlr] [backend/drm/drm.c:1116] 'DP-2' crtc=1 state=1 desired_enabled=1
00:00:00.588 [DEBUG] [wlr] [backend/drm/drm.c:1116] 'HDMI-A-1' crtc=-1 state=0 desired_enabled=0
00:00:00.588 [DEBUG] [wlr] [backend/drm/drm.c:1116] 'HDMI-A-2' crtc=-1 state=0 desired_enabled=0
00:00:00.588 [DEBUG] [wlr] [backend/drm/drm.c:1116] 'DVI-D-1' crtc=-1 state=0 desired_enabled=0
00:00:00.588 [DEBUG] [wlr] [backend/drm/drm.c:1167] State after reallocation:
00:00:00.588 [DEBUG] [wlr] [backend/drm/drm.c:1174] 'DP-1' crtc=0 state=1 desired_enabled=1
00:00:00.588 [DEBUG] [wlr] [backend/drm/drm.c:1174] 'DP-2' crtc=1 state=1 desired_enabled=1
00:00:00.588 [DEBUG] [wlr] [backend/drm/drm.c:1174] 'HDMI-A-1' crtc=-1 state=0 desired_enabled=0
00:00:00.588 [DEBUG] [wlr] [backend/drm/drm.c:1174] 'HDMI-A-2' crtc=-1 state=0 desired_enabled=0
00:00:00.588 [DEBUG] [wlr] [backend/drm/drm.c:1174] 'DVI-D-1' crtc=-1 state=0 desired_enabled=0
where DP-1 is than disabled. After suspend/resume, allocation turns into:
00:30:22.680 [DEBUG] [wlr] [backend/drm/drm.c:1099] Reallocating CRTCs
00:30:22.680 [DEBUG] [wlr] [backend/drm/drm.c:1110] State before reallocation:
00:30:22.680 [DEBUG] [wlr] [backend/drm/drm.c:1116] 'DP-1' crtc=-1 state=1 desired_enabled=0
00:30:22.680 [DEBUG] [wlr] [backend/drm/drm.c:1116] 'DP-2' crtc=1 state=3 desired_enabled=1
00:30:22.680 [DEBUG] [wlr] [backend/drm/drm.c:1116] 'HDMI-A-1' crtc=-1 state=0 desired_enabled=0
00:30:22.680 [DEBUG] [wlr] [backend/drm/drm.c:1116] 'HDMI-A-2' crtc=-1 state=0 desired_enabled=0
00:30:22.680 [DEBUG] [wlr] [backend/drm/drm.c:1116] 'DVI-D-1' crtc=-1 state=0 desired_enabled=0
00:30:22.680 [DEBUG] [wlr] [backend/drm/drm.c:1167] State after reallocation:
00:30:22.680 [DEBUG] [wlr] [backend/drm/drm.c:1174] 'DP-1' crtc=-1 state=1 desired_enabled=0
00:30:22.680 [DEBUG] [wlr] [backend/drm/drm.c:1174] 'DP-2' crtc=1 state=3 desired_enabled=1
00:30:22.680 [DEBUG] [wlr] [backend/drm/drm.c:1174] 'HDMI-A-1' crtc=-1 state=0 desired_enabled=0
00:30:22.680 [DEBUG] [wlr] [backend/drm/drm.c:1174] 'HDMI-A-2' crtc=-1 state=0 desired_enabled=0
00:30:22.680 [DEBUG] [wlr] [backend/drm/drm.c:1174] 'DVI-D-1' crtc=-1 state=0 desired_enabled=0
where the crtc for DP-1 is now NULL. Trying to enable the output results
in:
10:43:36.906 [DEBUG] [sway/config/output.c:351] Turning on output DP-1
10:43:36.906 [DEBUG] [sway/config/output.c:360] Set preferred mode
10:43:36.906 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.906 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.906 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.906 [DEBUG] [sway/config/output.c:366] Preferred mode rejected, falling back to another mode
10:43:36.906 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.906 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.906 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.906 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.906 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.906 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.906 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.906 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.906 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.906 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.906 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.906 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.906 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.906 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.906 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.906 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.906 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.906 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.906 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.906 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.906 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.906 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.906 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.906 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.906 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.906 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.906 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.906 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.906 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.906 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.906 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.906 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.906 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.906 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.906 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.906 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.906 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.906 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.906 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.906 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.906 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.906 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.906 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.906 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.906 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.906 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.907 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.907 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.907 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.907 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.907 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.907 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.907 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.907 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.907 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.907 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.907 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.907 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.907 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.907 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.907 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.907 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.907 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.907 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.907 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.907 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.907 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.907 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.907 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.907 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.907 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.907 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.907 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.907 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.907 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.907 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.907 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.907 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.907 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.907 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.907 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.907 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.907 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.907 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.907 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.907 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.907 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.907 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.907 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.907 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.907 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.907 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.907 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.907 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.907 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.907 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.907 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.907 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.907 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.907 [DEBUG] [sway/config/output.c:400] Auto-detected output scale: 1.000000
10:43:36.907 [DEBUG] [sway/config/output.c:430] Committing output DP-1
10:43:36.907 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-1: Can't enable an output without a buffer
10:43:36.907 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
10:43:36.907 [ERROR] [wlr] [types/wlr_output.c:512] Failed to get primary display formats
10:43:36.907 [ERROR] [sway/config/output.c:435] Failed to commit output DP-1
where the primary format can't be queried since there is no crtc
allocated for the connector. Allocating the connector inside
drm_connector_get_primary_formats() fixes this issue. This is possible
since the only user of get_primary_formats() is the swapchain allocation
function, which is only called on output enable. Do the same thing for
the cursor formats in case the user queries them before the output is
enabled.
This allows the kernel to access our buffer damage. Some drivers
can take advantage of this, e.g. for PSR2 panels (Panel Self
Refresh) or for transfer over USB.
Closes: https://github.com/swaywm/wlroots/issues/1267
This reverts commit 85757665e6.
We now check if the output is enabled within wlr_output_send_frame, no
need to handle this explicitly in the DRM backend. This also fixes a
race which was introduced with this commit: if we schedule the flip,
disable and commit the output before the flip happens,
output.frame_pending will not be reset to false. We than always fail to
enable the output subsequently:
00:07:13.276 [INFO] [sway/commands.c:257] Handling command 'output DP-2 enable'
00:07:13.276 [DEBUG] [sway/commands.c:428] Subcommand: enable
00:07:13.276 [DEBUG] [sway/config/output.c:204] Merging on top of existing output config
00:07:13.276 [DEBUG] [sway/config/output.c:227] Config stored for output DP-2 (enabled: 1) (-1x-1@-1.000000Hz position 0,0 scale -1.000000 subpixel unknown transform -1) (bg /home/phoenix/Pictures/Wallpapers/mine/oper.jpg fill) (dpms 1) (max render time: -1)
00:07:13.276 [DEBUG] [sway/config/output.c:351] Turning on output DP-2
00:07:13.276 [DEBUG] [sway/config/output.c:360] Set preferred mode
00:07:13.276 [DEBUG] [wlr] [backend/drm/drm.c:465] connector DP-2: Can't enable an output without a buffer
00:07:13.276 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
00:07:13.277 [DEBUG] [sway/config/output.c:329] Output DPI: 162.560000x161.364706
00:07:13.277 [DEBUG] [sway/config/output.c:400] Auto-detected output scale: 1.000000
00:07:13.277 [DEBUG] [sway/config/output.c:430] Committing output DP-2
00:07:13.277 [DEBUG] [wlr] [types/wlr_output.c:729] Tried to commit a buffer while a frame is pending
since the basic_output_test will always fail.
Reset frame_pending to false even if the output has been disabled in the
meantime.
Fixes https://github.com/swaywm/wlroots/issues/3109
When testing a modeset, make sure the caller has also provided a
buffer. This allows df0e75ba05 ("output: try skipping buffer
allocation if the backend allows it") to work as expected with the
DRM backend.
Closes: https://github.com/swaywm/wlroots/issues/3086
Unless we're dealing with a multi-GPU setup and the backend being
initialized is secondary, we don't need a renderer nor an allocator.
Stop initializing these.
Historically we haven't allowed direct scan-out for legacy KMS,
because legacy misses the functionality to make sure a buffer can
be scanned out. However with renderer v6 the backend can't figure
out anymore whether the buffer comes from its internal swap-chain,
because the backend doesn't have an internal swap-chain.
The legacy KMS API guarantees that the driver won't reject a buffer
as long as it's been allocated with the same parameters as the
previous one. Let's check this in legacy_crtc_test.
This is the cause of the spurious "drmHandleEvent failed" messages
at exit. restore_drm_outputs calls handle_drm_event in a loop without
checking whether the FD is readable, so drmHandleEvent ends up with a
short read (0 bytes) and returns an error.
The loop's goal is to wait for all queued page-flip events to complete,
to allow drmModeSetCrtc calls to succeed without EBUSY. The
drmModeSetCrtc calls are supposed to restore whatever KMS state we were
started with. But it's not clear from my PoV that restoring the KMS
state on exit is desirable.
KMS clients are supposed to save and restore the (full) KMS state on VT
switch, but not on exit. Leaving our KMS state on exit avoids unnecessary
modesets and allows flicker-free transitions between clients. See [1]
for more details, and note that with Pekka we've concluded that a new
flag to reset some KMS props to their default value on compositor
start-up is the best way forward. As a side note, Weston doesn't restore
the CRTC by does disable the cursor plane on exit (see
drm_output_deinit_planes, I still think disabling the cursor plane
shouldn't be necessary on exit).
Additionally, restore_drm_outputs only a subset of the KMS state.
Gamma and other atomic properties aren't accounted for. If the previous
KMS client had some outputs disabled, restore_drm_outputs would restore
a garbage mode.
[1]: https://blog.ffwll.ch/2016/01/vt-switching-with-atomic-modeset.html
wl_event_loop_add_fd was called with a NULL data argument, but the
function expects the data argument to be set to the wlr_drm_backend.
Fixes: 053ebe7c27 ("backend/drm: terminate display on drmHandleEvent failure")
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).
drm_surface_make_current and drm_surface_unset_current set implicit
state and are an unnecessary mid-layer. Prefer to use directly
wlr_renderer_begin_with_buffer, which automatically unsets the back
buffer on wlr_renderer_end.
I'd like to get rid of drm_surface_make_current once we stop using
it for the primary swapchain.
Some buffers need to be copied across GPUs. Such buffers need to be
allocated with a format and modifier suitable for both the source
and the destination.
When explicit modifiers aren't supported, we were forcing the buffers
to be allocated with a linear layout, because implicit modifiers
aren't portable across GPUs. All is well with this case.
When explicit modifiers are supported, we were advertising the whole
list of destination modifiers, in the hope that the source might
have some in common and might be able to allocate a buffer with a
more optimized layout. This works well if the source supports explicit
modifiers. However, if the source doesn't, then wlr_drm_format_intersect
will fallback to implicit modifiers, and everything goes boom: the
source uses a GPU-specific tiling and the destination interprets it
as linear.
To avoid this, just force linear unconditionally. We'll be able to
revert this once we have a good way to indicate that an implicit modifier
isn't supported in wlr_drm_format_set, see [1].
[1]: https://github.com/swaywm/wlroots/pull/2815
Closes: https://github.com/swaywm/wlroots/issues/3030
[1] and [2] have introduced new wl_array usage in wlroots, but
contains a mistake: wl_array_for_each iterates over pointers to
the wl_array entries, not over entries themselves.
Fix all wl_array_for_each call sites. Name the variables "ptr"
to avoid confusion.
Found via ASan:
==148752==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x602000214111 in thread T0
#0 0x7f6ff2235f19 in __interceptor_free /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:127
#1 0x7f6ff1c04004 in wlr_tablet_destroy ../subprojects/wlroots/types/wlr_tablet_tool.c:24
#2 0x7f6ff1b8463c in wlr_input_device_destroy ../subprojects/wlroots/types/wlr_input_device.c:51
#3 0x7f6ff1ab9941 in backend_destroy ../subprojects/wlroots/backend/wayland/backend.c:306
#4 0x7f6ff1a68323 in wlr_backend_destroy ../subprojects/wlroots/backend/backend.c:57
#5 0x7f6ff1ab36b4 in multi_backend_destroy ../subprojects/wlroots/backend/multi/backend.c:57
#6 0x7f6ff1ab417c in handle_display_destroy ../subprojects/wlroots/backend/multi/backend.c:124
#7 0x7f6ff106184e in wl_display_destroy (/usr/lib/libwayland-server.so.0+0x884e)
#8 0x55cd1a77c9e5 in server_fini ../sway/server.c:218
#9 0x55cd1a77893f in main ../sway/main.c:400
#10 0x7f6ff04bdb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#11 0x55cd1a73a7ad in _start (/home/simon/src/sway/build/sway/sway+0x33a7ad)
0x602000214111 is located 1 bytes inside of 16-byte region [0x602000214110,0x602000214120)
freed by thread T0 here:
#0 0x7f6ff2235f19 in __interceptor_free /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:127
#1 0x7f6ff1c04004 in wlr_tablet_destroy ../subprojects/wlroots/types/wlr_tablet_tool.c:24
#2 0x7f6ff1b8463c in wlr_input_device_destroy ../subprojects/wlroots/types/wlr_input_device.c:51
#3 0x7f6ff1ab9941 in backend_destroy ../subprojects/wlroots/backend/wayland/backend.c:306
#4 0x7f6ff1a68323 in wlr_backend_destroy ../subprojects/wlroots/backend/backend.c:57
#5 0x7f6ff1ab36b4 in multi_backend_destroy ../subprojects/wlroots/backend/multi/backend.c:57
#6 0x7f6ff1ab417c in handle_display_destroy ../subprojects/wlroots/backend/multi/backend.c:124
#7 0x7f6ff106184e in wl_display_destroy (/usr/lib/libwayland-server.so.0+0x884e)
previously allocated by thread T0 here:
#0 0x7f6ff2236279 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7f6ff1066d03 in wl_array_add (/usr/lib/libwayland-server.so.0+0xdd03)
[1]: https://github.com/swaywm/wlroots/pull/3002
[2]: https://github.com/swaywm/wlroots/pull/3004
The previous fix tried to side-step cursor->pending_fb completely.
However that messes up our buffer locking mechanism.
Instead, stop clearing the pending cursor FB on a failed commit. The
pending cursor FB will remain for the next commit.
Fixes: 6c3d080e25 ("backend/drm: populate cursor plane's current_fb")
This reverts commit 6c3d080e25.
Populating wlr_drm_plane.current_fb messes up the buffer's locking.
The previous buffer is released while it's still being displayed
on-screen.
Custom backends and renderers need to implement
wlr_backend_impl.get_buffer_caps and
wlr_renderer_impl.get_render_buffer_caps. They can't if enum
wlr_buffer_cap isn't made public.
Right now, when a new output state field is added, all backends by
default won't reject it. This means we need to add new checks to
each and every backend when we introduce a new state field.
Instead, introduce a bitmask of supported output state fields in
each backend, and error out if the user has submitted an unknown
field.
Some fields don't need any backend involvment to work. These are
listed in WLR_OUTPUT_STATE_BACKEND_OPTIONAL as a convenience.
This moves the magic incantation into libdrm and is clearer. See
[1] for details.
While at it, fixup the doc comment and improve logging.
[1]: 523b3658aa
The set_cursor() hook is a little bit special: it's not really
synchronized to commit() or test(). Once set_cursor() returns true,
the new cursor is part of the current state.
This fixes a state where wlr_drm_connector.cursor_enabled is true
but there is no FB available. This is triggered by set_cursor()
followed by a failed commit(), which resets pending_fb.
We should definitely fix the output interface to make the cursor part
of the pending state, but that's a more involved change.
Instead of trying to perform a real modeset in init_renderer,
perform an atomic test-only commit to find out whether disabling
modifiers is necessary because of bandwidth limitations.
This decouples init_renderer from the actual commit, making it
possible to modeset an output with a user-supplied buffer instead
of a black frame.
We loose the ability to make sure the buffers coming from the
swapchain will work fine when using the legacy interface. This
can break i915 when atomic is disabled and modifiers enabled.
But i915 always has atomic (so the user must explicitly disable it
to run into potential bandwidth limitations) and is the only known
problematic driver.
Rely on wlr_output's generic swapchain support instead of creating our
own. The headless output now simply keeps a reference to the front buffer
and does nothing else.
Instead of passing a wlr_texture to the backend, directly pass a
wlr_buffer. Use get_cursor_size and get_cursor_formats to create
a wlr_buffer that can be used as a cursor.
We don't want to pass a wlr_texture because we want to remove as
many rendering bits from the backend as possible.
When picking a format, the backend needs to know whether the
buffers allocated by the allocator will be DMA-BUFs or shared
memory. So far, the backend used the renderer's supported
buffer types to guess this information.
This is pretty fragile: renderers in general don't care about the
SHM cap (they only care about the DATA_PTR one). Additionally,
nothing stops a renderer from supporting both DMA-BUFs and shared
memory, but this would break the backend's guess.
Instead, use wlr_allocator.buffer_caps. This is more reliable since
the buffers created with the allocator are guaranteed to have these
caps.
Instead of managing our own renderer and allocator, let the common
code do it.
Because wlr_headless_backend_create_with_renderer needs to re-use
the parent renderer, we have to hand-roll some of the renderer
initialization.
