| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Make it so wlr_gles2_texture is ref'counted (via wlr_buffer). This
is similar to wlr_gles2_buffer or wlr_drm_fb work.
When creating a wlr_texture from a wlr_buffer, first check if we
already have a texture for the buffer. If so, increase the
wlr_buffer ref'count and make sure any changes made by an external
process are made visible (by invalidating the texture).
When destroying a wlr_texture created from a wlr_buffer, decrease
the ref'count, but keep the wlr_texture around in case the caller
uses it again. When the wlr_buffer is destroyed, cleanup the
wlr_texture.
|
|
This adds a a function to create a wlr_texture from a wlr_buffer.
The main motivation for this is to allow the renderer to create a
single wlr_texture per wlr_buffer. This can avoid needless imports
by re-using existing textures.
|
|
This allows the DMA-BUF wl_buffer objects to be used directly as
wlr_buffers, without having to use wlr_client_buffer_import.
|
|
Users can just access the width/height fields directly.
|
|
|
|
|
|
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.
|
|
All of the information is in wlr_output_state.
|
|
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.
|
|
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.
|
|
Same as wlr_allocator_autocreate, but allows the caller to force a
DRM FD.
Similar to renderer_autocreate_with_drm_fd.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Allow wlr_buffer_impl.get_data_ptr to return a format.
This allows the Pixman renderer to not care about get_dmabuf/get_shm,
and only care about get_data_ptr. This will also help with [1], because
client wl_shm buffers can't implement get_shm.
[1]: https://github.com/swaywm/wlroots/pull/2892
References: https://github.com/swaywm/wlroots/issues/2864
|
|
|
|
Any use of the DRM FD after the remove event results in a "Permission
denied" error.
|
|
|
|
|
|
`_NET_WM_PID` is unreliable: it is optional and even if set it may
contain PIDs from sandbox namespaces or remote systems.
Prefer XRes v1.2 QueryClientIds method which returns PIDs as seen by the
Xwayland server.
|
|
|
|
|
|
|
|
|
|
Previously, the same struct was used for linux-dmabuf-v1 params
and buffer. This made the whole logic a little bit awkward, because
a wlr_dmabuf_v1_buffer could either be still being constructed, or
be a complete buffer.
Introduce a separate wlr_linux_buffer_params_v1 struct for buffer
params still being constructed. Once the params are complete (ie.
once the create request is sent), the params struct is destroyed
and the buffer struct is created.
This will help with [1] as well.
[1]: https://github.com/swaywm/wlroots/issues/2664
|
|
Drop wlr_dmabuf_v1_buffer_from_params_resource and
wlr_linux_dmabuf_v1_from_resource. Contrary to wl_buffer, these
resources are internal linux-dmabuf-v1 implementation details and
should not be shared with other interfaces.
|
|
Allow selecting whether the GLES2 renderer gets enabled.
Co-authored-by: Simon Ser <contact@emersion.fr>
|
|
|
|
|
|
It allocates in local main memory via shm_open, and provides a FD
to allow sharing with other processes.
This is suitable for software rendering under the Wayland and X11
backends.
|
|
References: https://github.com/swaywm/wlroots/issues/2399#issuecomment-769408708
|
|
The function has been place in an internal header for API stability
reasons.
|
|
|
|
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.
|
|
This is instead delegated to libseat.
|
|
|
|
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.
|
