| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Destroy the struct wlr_wl_seat when the global is removed.
|
|
Instead of destroying all seats, destroy a single one. We only need
to destroy all seats at one call-site (backend_destroy), but we'll
need to destroy a single seat elsewhere in the next commit.
|
|
The hardcoded fallback "/usr/share/hwdata/pnp.ids" was only a
temporary solution to get things working while distributions were
still working on shipping it.
|
|
Do not update the output mode if the commit failed in one of the
error codepaths.
|
|
During a modeset, the core wlr_output logic will allocate a buffer
with a new size and commit it. However if we still have a frame
callback pending we'd refuse to perform the commit. This is
inconsistent with the DRM backend, which performs a blocking
modeset.
This is visible when resizing the Wayland toplevel. The logs are
filled with "Skipping buffer swap", and the wlr_damage_ring's
bounds are not properly updated.
Fix this by destroying the pending frame wl_callback.
|
|
Because wl_buffer.release is per-buffer and not per-commit, the
Wayland backend might create multiple struct wlr_wl_buffer per
struct wlr_buffer. As a result, the wlr_buffer_unlock() call inside
destroy_wl_buffer() can cause another struct wlr_wl_buffer to be
destroyed.
In backend_destroy() we were iterating the list of buffers with
wl_list_for_each_safe(), which is actually not safe in this case:
the next buffer is cached, but might be destroyed as a side-effect
of calling destroy_wl_buffer().
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3572
|
|
Since 1d581656c756 ("backend/drm: set "max bpc" to the max") we
set the "max bpc" property to the maximum value. The kernel driver
is supposed to clamp this value depending on hardware capabilities.
All kernel drivers lower the value depending on the GPU capabilities.
However, none of the drivers lower the value depending on the DP-MST
link capabilities. Thus, enabling a 4k@60Hz mode can fail on some
DP-MST setups due to the "max bpc" property.
Additionally, it's not a good idea to unconditionally set "max bpc"
to the max. A high bpc consumes more lanes and more clock speed,
which means higher power consumption and the busy lanes cannot be
used for something else (e.g. other data transfers on a USB-C cable).
For now, let's tie the "max bpc" to the pixel format of the buffer.
Introduce a heuristic to make "high bit-depth buffer" a synonym of
"I want the best quality".
This is not perfect: a "max bpc" higher than 8 might be desirable
for pixel formats with a color depth of 8 bits, for instance when
the color management KMS properties are used. But we don't really
support that yet, so let's leave this for later.
Closes: https://github.com/swaywm/sway/issues/7367
|
|
When the user switches away from the VT where wlroots is running,
the new DRM master may mutate the KMS state in an arbitrary manner.
For instance, let's say wlroots uses the following connector/CRTC
mapping:
- CRTC 42 drives connector DP-1
- CRTC 43 drives connector DP-2
Then the new DRM master may swap the mapping like so:
- CRTC 42 drives connector DP-2
- CRTC 43 drives connector DP-1
wlroots needs to restore its own state when the user switches back.
Some state is attached to wlr_drm_crtc (e.g. current FB), so reading
back and adopting the CRTC/connector mapping left by the previous DRM
master would be complicated (this was the source of other bugs in the
past, see [1]).
With the previous logic, wlroots merely tries to restore the state
of each connector one after the other. This fails in the scenario
described above: the kernel refuses to use CRTC 42 for DP-1, because
that CRTC is already in-use for DP-2.
Unfortunately with the legacy uAPI it's not possible to restore the
state in one go. We need to support both legacy and atomic uAPIs, so
let's fix the bug for the legacy uAPI first, and then improve the
situation for the atomic uAPI as a second step [2].
We need to disable the CRTCs we're going to switch the connectors for.
This sounds complicated, so let's just disable all CRTCs to simplify.
This causes a black screen because of the on/off modesets, but makes
VT switch much more reliable, so I'll take it.
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/commit/c6d8a11d2c438d514473b1cbe20e5550e7227472
[2]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3794
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3342
|
|
Fixes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3563
|
|
We lock the buffer there, so we need to initialize the n_busy
count to 1 as well.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3556
|
|
We already do it for get_drm_plane_props().
|
|
We only need it for one thing: gamma size. Moreover, some bits in
the drmModeCrtc will become out-of-date, for instance the current
mode, so let's avoid caching the whole struct and only keep what
we know won't change.
|
|
connect_drm_connector() may be called long after create_drm_connector().
During that time the DRM mode might have changed. Avoid working with
stale information.
|
|
|
|
If the kernel adds new enum entries for subpixel, don't read past
the end of the subpixel_map array.
|
|
match_obj() might return a configuration where the CRTC for an
enabled connector is switched to another one.
We don't support this correctly: the wlr_output common code would
need to query again the supported formats, re-allocate the
swapchain, etc.
What's more, the kernel doesn't even support this [1]: it
requires planes to be disabled to change their CRTC, it rejects
commits directly switching the CRTC used by a plane.
[1]: https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/drm_atomic.c?h=6e90293618ed476d6b11f82ce724efbb9e9a071b#n697
|
|
This list contains wlr_drm_connector entries, and there is no
guarantee that the wlr_output fields are initialized.
|
|
Ensure we unlock any pending cursor FB when disabling a connector.
|
|
If the commit fails, then our local state becomes out-of-sync with
the kernel's. Additionally, when disabling a connector without going
through dealloc_crtc(), conn->crtc would still be set.
Fix this by updating conn->crtc in drm_connector_commit_state().
|
|
The raw enum value wasn't informative enough. It's not trivial to
tell whether 0 means connected or disconnected.
Drop the status from the state after realloc, since the exact same
information is printed right above.
|
|
Helper to stringify a connector status.
|
|
Instead of having a pending_fb field on the struct wlr_drm_plane,
move it to struct wlr_drm_connector_state. That way, there's no
risk having a stale pending FB around: the state doesn't survive
across tests and commits.
The cursor is a special case because it's disconnected from the
atomic state: the wlr_backend_impl.set_cursor hook sets the cursor
for the next commit. Move the field to
wlr_drm_connector.cursor_pending_fb.
|
|
We'll move the pending primary FB into the connector state in the
next commit, dropping wlr_drm_plane.pending_fb in the process.
Introduce a dedicated field for the cursor, which has to be managed
in a special way due to our set_cursor API.
|
|
plane_get_next_fb() will go away in subsequent commits. Primary and
cursor will differ with the new logic. Let's prepare for this.
|
|
We only have one error code-path, no need for goto here.
|
|
No need to manually call drm_connector_state_init() here, we can
just let drm_connector_commit_state() handle it.
|
|
We were calling drm_connector_supports_vrr() before
drm_connector_alloc_crtc(). Thus, when an output is currently off,
the VRR test would always fail, because it checks that the
vrr_enabled CRTC prop exists.
|
|
We sometimes used HAS_, sometimes polluted the LIBINPUT_ namespace,
etc.
|
|
Removes project arguments.
|
|
|
|
destroy_wl_buffer() is called from backend_destroy(). We need to
ensure the wlr_buffer is unlocked when we're waiting for a
wl_buffer.release event from the parent compositor.
|
|
Some compositors are not interested in wlr_session, for instance
nested compositors.
Disabling wlr_session removes the udev dependency.
|
|
Instead of hand-rolling get_current_time_msec(), let's just re-use
the helper we already have in "util/time.h".
|
|
Instead of returning an empty multi backend, fail with a clear
error when both the DRM and libinput backends are disabled.
|
|
We have no use for these.
|
|
There's no reason why the output should be damaged here. The current
buffer doesn't need to be re-painted.
|
|
Backends no longer need to manually call wlr_output_update_enabled()
in their commit hook: wlr_output will take care of that.
|
|
This function deals with multiple kinds of backends. Make it more
obvious that this variable holds the multi backend which is returned
to the user.
|
|
This no longer has purpose.
|
|
Up until now, wlr_backend_autocreate() created the wlr_session and
then stuffed it into struct wlr_multi_backend so that compositors
can grab it later.
This is an abuse of wlr_multi_backend and the wlr_backend API:
wlr_backend_get_session() and wlr_multi_backend.session only exist
to accomodate the needs of wlr_backend_autocreate(). What's more,
the DRM and libinput backends don't implement
wlr_backend_impl.get_session.
Instead, return the struct wlr_session to the compositor in the
wlr_backend_autocreate() call. wlr_backend_get_session() will be
removed in the next commit.
|
|
|
|
|
|
It doesn't make sense to request a page-flip for a disabled output.
Fixes: 84e727daae67 ("backend/drm: request page-flip event on modeset")
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3528
|
|
Fixes: 65836ce357e4 ("backend/drm: log modesetting commits")
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3534
|
|
|
|
|
|
Pixman 0.42.0 has constified APIs for pixman_region32_t. We no longer
need the casts.
|
|
The DRM, libinput and session use udev. They are all hosted under
backend/.
|
|
The following situation can be dangerous:
- Output DP-1 is plugged in, compositor enables it.
- User VT switches away.
- User unplugs DP-1.
- User VT switches back.
- scan_drm_connectors() figures out the output is now disconnected,
uninitializes the struct wlr_output.
- The loop restoring previous output state in handle_session_active()
accesses the struct wlr_output to figure out what to restore.
By chance, we zero out the struct wlr_output after uninitializing it,
so enabled and current_mode will always be zero. But let's make sure
we handle this case explicitly, to remind future readers that it exists
and make the code less fragile.
|
