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.
This new functions cleans up the common backend state. While this
currently only emits the destroy signal, this will also clean up
the renderer and allocator in upcoming patches.
Backend-initiated mode changes can use this function instead of
going through drm_connector_set_mode. drm_connector_set_mode becomes
a mere drm_connector_commit_state helper.
Replace it with a new drm_connector_state_is_modeset function that
decides whether a modeset is necessary directly from the
wlr_output_state which is going to be applied.
Populate the wlr_output_state when setting a mode. This will allow
drm_connector_set_mode to stop relying on ephemeral fields in
wlr_drm_crtc. Also drm_connector_set_mode will be able to apply
both a new buffer and a new mode atomically.
Stop assuming that the state to be applied is in output->pending in
crtc_commit. This will allow us to remove ephemeral fields in
wlr_drm_crtc, which are used scratch fields to stash temporary
per-commit data.
On multi-GPU setups, there is a primary DRM backend and secondary
DRM backends. wlr_backend_get_drm_fd will always return the parent
DRM FD even on secondary backends, so that users always use the
primary device for rendering.
However, for our internal rendering we want to use the secondary
device. Use allocator_autocreate_with_drm_fd to make sure the
allocator will create buffers on the secondary device.
We do something similar to ensure our internal rendering will
happen on the secondary device with renderer_autocreate_with_drm_fd.
Fixes: cc1b66364c ("backend: use wlr_allocator_autocreate")
This function is only required because the DRM backend still needs
to perform multi-GPU magic under-the-hood. Remove the wlr_ prefix
to make it clear it's not a candidate for being made public.
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.
libseat provides all session functionality, so there is no longer need
for a session backend abstraction. The libseat device ID, seat handle
and event loop handle are moved to the main wlr_session and wlr_device
structs.
The get_drm_fd was made available in an internal header with a53ab146f. Move it
now to the public header so consumers opting in to the unstable interfaces can
make use of it.
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.
wlroots' dependency on this library doesn't change the features
exposed to compositors. It's purely a wlroots implementation detail.
Thus downstream compositors shouldn't really care about it.
Introduce an "internal_features" dictionary to store the status of
such internal dependencies.
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.
This allows libseat to be compiled as a Meson subproject when it's
not installed system-wide. This can ease development and compilation
on distributions where libseat isn't packaged.
Split render/display setups have two separate devices: one display-only
with a primary node, and one render-only with a render node. However
in these cases the EGL implementation and the Wayland compositor will
advertise the display device instead of the render device [1]. The EGL
implementation will magically open the render device when the display
device is passed in.
So just pass the display device as if it were a render device. Maybe in
the future Mesa will advertise the render device instead and we'll be
able to remove this workaround.
[1]: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4178
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.
When a new texture is set, the hotspot may actually belong to the
previous texture and be out of bounds. Rather than incur X errors for
these, clamp the hotspot to be inside of the texture.
This fixes weston examples updating their cursors (e.g.
weston-eventdemo).
It turns out wl_event_source_check is not enough to guarantee that the
remote wl_display will be flushed after we queue requests. We need to
explicitly flush, just like we do in our X11 code.
References: https://gitlab.freedesktop.org/wayland/wayland/-/issues/187
When we receive an Expose event, that means that we must redraw that
region of the X11 window. Keep track of these regions with pixman
regions, and merge them with the additional output damaged regions.
Fixes#2670
The region variable was shadowed in an if block. As a result, in the
outer block region was always XCB_NONE and was never destroyed (causing
a memory leak on the server).
Reported-by: Ilia Mirkin <imirkin@alum.mit.edu>
This actually simplifies the logic since we no longer have to wait for
enter/leave events, and also improves the UX when e.g. handling a crash
with gdb attached.
See #2659
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.
keyboard_handle_leave would always process 1 keycode more than was
pending, which meant reading uninitialized memory from the "pressed"
array.
Found by valgrind.
Sometimes wlr_session_find_gpus will encounter an error. This is
different from finding zero GPUs.
On error, wlr_session_find_gpus already returns -1. However, this is
casted to size_t, so callers uncorrectly assume this is a success.
Instead, make wlr_session_find_gpus return a ssize_t and allow callers
to handle the error accordingly.
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
If we get an authenticated primary node from the X11 server, don't use
it because we can't authenticate our Wayland clients with it. Instead,
open a render node.
Closes: https://github.com/swaywm/wlroots/issues/2576
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/
The Present protocol states:
> An event context is associated with a specific window; using an existing
> event context with a different window generates a Match error.
Instead of a global event context, use a per-window event context to fix
this error:
[backend/x11/backend.c:608] X11 error: op Present (SelectInput), code Match (no extension), sequence 63, value 4194307
Closes: https://github.com/swaywm/wlroots/issues/2577
Instead of using a timer, rely on X11 Present events and send a new
frame event when the parent compositor displays a new frame on screen.
The previous attempt at doing this [1] hit issues with EGLSurface, but
we don't use that anymore.
[1]: https://github.com/swaywm/wlroots/pull/1894
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
We queried DRI3 formats, but we weren't using them. Because of a typo,
only render formats were used.
Fixes: c59aacf944 ("backend/x11: query modifiers supported by X11 server")
Closes: https://github.com/swaywm/wlroots/issues/2552
Backends will eventually stop creating their renderer. To prepare for
this, stop using EGL_PLATFORM_SURFACELESS_MESA in the headless renderer.
Pick a render node using libdrm.
The new allocator/renderer creation logic looks very much like what will
end up in common code.
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.
- The DRM backend initially doesn't have a frame scheduled initially.
However the compositor is expected to set a mode to start the
rendering loop (frame_pending is set to true in drm_crtc_pageflip).
- The headless and X11 backends have a timer to schedule frames, so they
ignore this hint completely.
- The Wayland backend renders a fake frame to start the rendering loop.
It's the only case where a frame is pending on init, move the
assumption there.
I was about to add a check to fail instead of crash when the compositor
uses direct scan-out, but with renderer v6 it's so simple to just add
support for direct scan-out, why bother?
Closes: https://github.com/swaywm/wlroots/issues/2523
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.
The Wayland platform doesn't have visuals. By chance,
WL_SHM_FORMAT_ARGB8888 is zero, which means egl_get_config was ignoring
it and everything worked fine.
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
Wait for a DRM device if none is found in wlr_session_find_gpus. This
can happen if the compositor is loaded before the display kernel driver.
This supersedes the logind CanGraphical property.
To test, e.g. with i915 and sway:
rmmod -f i915
sway &
modprobe i915
Closes: https://github.com/swaywm/wlroots/issues/2093
We're only interested in card devices. The loop over wlr_session.devices
would take care of ignoring non-card events, but a future patch will
listen to udev "add" events as well.
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
We have the policy of requiring up-to-date dependencies instead of
adding conditionals for older versions. libinput 1.14 was published more
than 1 year ago.
Every host seat with pointer capability propagates events to one of
sub-pointer depending which output window we entered.
active_pointer tracks reference to sub-pointer on enter/leave events to
avoid lookup for it on every move events.
Fixesswaywm/wlroots#1499
This effectively gets swaywm/wlroots#1499 to the point where
functionality somewhat preserved and no crash happens.
We still can have only one cursor, but we can control it from multiple
seats in time-sharing manner by entering/leaving output.
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.
I'm not sure what this was used for, but it's not used by libwayland.
Setting _WAYLAND_DISPLAY would result in the Wayland backend being
picked but would ignore the actual value of the env variable.
When starting a compositor that's using the "direct" session backend,
wlroots needs to handle calls to `drmSetMaster()` and `drmDropMaster()`.
As both calls used to require `CAP_SYS_ADMIN`, wlroots thus simply
refused starting in case the process doesn't enjoy evelated privileges.
Permission rules have changed since linux.git commit 45bc3d26c95a (drm:
rework SET_MASTER and DROP_MASTER perm handling, 2020-03-19). As a
result, starting with Linux v5.8, both ioctls will now also succeed if
the process is currently or has been the DRM master. And as the first
process to open render nodes will become the DRM master automatically,
this effectively means that process elevation is not strictly required
in all setups anymore.
So let's drop the `geteuid() != 0` permission check to allow those new
rules to do their magic.
bad1e9afa8 ("session: Add libseat backend") introduced a change to to
how session backends initialize, but failed to update the FreeBSD
specific version of the direct backend accordingly.
Closes: https://github.com/swaywm/wlroots/issues/2376
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 commit makes `get_current_time_msec` correctly return milliseconds
as opposed to microseconds. It also considers the value of `tv_sec`, so
we don't lose occasionally go back in time by one second. Finally, the
function is moved into `util/time.cc` so that it can be reused elsewhere
without having to consider these pitfalls.
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
When calling assert(0) instead of returning a value, -Wreturn-type
warnings are triggered because assertions can be disabled. Replace these
assertions with abort().
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.
We don't need a per-CRTC atomic request anymore. Let's make the request
per-commit so that it's easier to debug.
This is also groundwork for supporting wlr_output_test properly.
GAMMA_LUT_SIZE isn't an atomic property. It can be used with the legacy
interface too. So we can unify both codepaths and remove
wlr_drm_interface.crtc_get_gamma_size.
It's no guaranteed to exist though, so we still need to keep the
fallback.
