| Age | Commit message (Collapse) | Author |
|---|
|
See 757e26712337 ("drm/uapi: Add USB connector type") in the kernel
tree.
|
|
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: 053ebe7c278b ("backend/drm: terminate display on drmHandleEvent failure")
|
|
We were missing destroy calls for gestures, and we were only
destroying the relative pointer on output destroy.
|
|
This is now provided by the generic wlr_output implementation.
|
|
This is now provided by the generic wlr_output implementation.
|
|
The callee can just get it from the wlr_drm_connector.
|
|
Now that we have a test_only arg in crtc_commit, we can move the
legacy checks to legacy.c.
|
|
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: 6c3d080e25e5 ("backend/drm: populate cursor plane's current_fb")
|
|
This reverts commit 6c3d080e25e56404228ad7704eed43e40fa0c623.
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.
|
|
Instead of using a single-field wl_list, let's just use a wl_array.
|
|
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.
|
|
|
|
|
|
|
|
This is more consistent with the rest of the wlroots naming.
|
|
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.
|
|
Instead of hardcoding the string "card", use DRM_PRIMARY_MINOR_NAME.
Some systems may use another prefix, e.g. OpenBSD uses "drm" instead.
|
|
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]: https://gitlab.freedesktop.org/mesa/drm/-/commit/523b3658aa8efa746417e916c987de23740ce313
|
|
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, call drm_connector_set_pending_fb.
|
|
The other caller (drm_connector_commit_state) already checks this.
|
|
This will be used in drm_connector_test shortly.
|
|
We can't perform a test-only atomic commit if the connector is
missing a CRTC.
|
|
drm_connector_set_pending_fb needs a CRTC to import the buffer.
|
|
This function allocates a CRTC for a connector if necessary.
|
|
Set the plane's pending FB before calling drm_connector_set_mode.
|
|
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.
|
|
Make it clear this function is a private wlroots API and will stay
that way.
|
|
|
|
Rely on wlr_output's generic swapchain handling.
|
|
|
|
Rely on wlr_output's generic swapchain handling.
We still need a renderer for cursor readback, sadly.
|
|
|
|
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.
|
|
Doesn't make a lot of sense to split the cursor fields between
wlr_drm_plane and wlr_drm_connector. Let's just move everything to
wlr_drm_connector.
|
|
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.
|
|
This is a new helper function to pick a render format suitable for
a plane.
The next commit will use it to initialize the cursor multi-GPU
surface.
|
|
This was always set to ARGB8888.
|
|
|
|
|
|
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.
|
