| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
Instead of managing our own renderer and allocator, let the common
code do it.
|
|
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.
|
|
Instead of managing our own renderer and allocator, let the common
code do it.
|
|
Introduce a new backend_get_allocator function that automatically
creates an allocator for the backend if the backend has a renderer.
|
|
If a backend accepts buffers (as indicated by get_buffer_caps) but
doesn't implement get_renderer, automatically create a renderer.
|
|
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.
|
|
|
|
If a mode is not provided, use the current mode intead.
Closes: https://github.com/swaywm/wlroots/issues/2904
|
|
We were not dup'ing the DRM FD coming from wlr_renderer_get_drm_fd,
resulting in a double-close on backend destroy.
|
|
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.
|
|
No need to take a generic wlr_output, we already know the output
comes from the DRM backend at that point.
|
|
This will allow a whole state to be applied at once, instead of
individually applying the buffer and the mode.
|
|
All of the information is in wlr_output_state.
|
|
This is now unused.
|
|
Replace it with drm_connector_state_mode, which computes the mode
from the wlr_output_state to be applied.
|
|
Replace it with drm_connector_state_active, which figures out
whether the connector is active depending on the wlr_output_state
to be applied.
|
|
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.
|
|
Instead of relying on wlr_output.pending to be empty when performing
backend-initiated CRTC commits, use a zero wlr_output_state.
|
|
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: cc1b66364cc9 ("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.
|
|
Remove the assumption about EGL.
|
|
Makes it easier to figure out why a backend/renderer is picked.
|
|
|
|
|
|
|
|
|
|
This reverts commit f9f90b417366581b58d806956c9b2099417ed4b3.
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
|
|
On GPU unplug, disabling a CRTC can fail with EPERM.
References: https://github.com/swaywm/wlroots/pull/2575#issuecomment-761771264
|
|
Any use of the DRM FD after the remove event results in a "Permission
denied" error.
|
|
|
|
|
|
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.
|
|
|
|
|
