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).
