| 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.
|
|
Some formats have a byte-per-pixel lower than 1. Let's not encode
an arbitrary limitation into the wlr_renderer API.
|
|
When the matrix doesn't have a rotation, we can avoid a sqrt() call.
Tested with Sway's tabbed containers.
|
|
See [1]. This allows us to remove the workaround for GBM API
limitations.
[1]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5442
|
|
|
|
We can just use the wlr_dmabuf_v1_buffer directly, no need to wrap
it in a wlr_client_buffer.
|
|
|
|
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 centralizes the wlr_texture initialization.
In future commits, more fields will need to get initialized.
|
|
This allows the DMA-BUF wl_buffer objects to be used directly as
wlr_buffers, without having to use wlr_client_buffer_import.
|
|
We require the ext in the renderer init function.
|
|
Users can just access the width/height fields directly.
|
|
eec2e1d3b16ba40c85483badcc7809277274ce5d introduced logic to use the Xwayland
binary discovered via pkg-config.
While the newly introduced checks correctly used the binary from pkg-config,
the actual execution still used the previous PATH-search logic.
|
|
GL_RENDERER typically displays a human-readable string for the name
of the GPU, and EGL_VENDOR typically displays a human-readable string
for the GPU manufacturer. EGL_DRIVER_NAME_EXT should give the name of
the driver in use.
References: https://github.com/KhronosGroup/EGL-Registry/commit/e8baa0bf39120803505c6e360e1e33af0d9b9745
|
|
According to libinput, release events are generated when device is unplugged,
and libinput copies this behavior for device removal. Let's do the same for
our virtual keyboard.
https://github.com/wayland-project/libinput/commit/8f846a41fa0566fbd72ece676656e20e56ce43e6
This is another attempt to fix #2034 and the following sway issue:
https://github.com/swaywm/sway/issues/6254
Note that we have other key repeating issues in sway, which aren't addressed
by this patch. Since the virtual keyboard itself isn't destroyed when the
keyboard grab is destroyed, we'll probably need some trick to reset the state
of the corresponding virtual keyboard when the grab is released.
https://github.com/swaywm/sway/issues/6095
https://github.com/swaywm/sway/issues/6193
|
|
|
|
|
|
The libXcursor fix for CVE-2013-2003 has never been imported into
wlroots, leaving it vulnerable to it.
Changing the argument type to an unsigned type is an effective merge of
Ilja Van Sprundel's commit in libXcursor.
Proof of Concept (compile with address sanitizer):
$ mkdir -p ~/.local/share/icons/poc/cursors
$ base64 -d <<< WGN1chAAAAAAAAAA/////w== > \
~/.local/share/icons/poc/cursors/poc
$ echo "seat seat0 xcursor_theme poc 10" > ~/poc-config
$ sway -c ~/poc-config
|
|
|
|
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.
|
|
Rendering a wlr_texture with a different wlr_renderer is invalid.
Add an assert to make sure this doesn't happen.
|
|
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")
|
|
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.
|
|
Remove the assumption about EGL.
|
|
Makes it easier to figure out why a backend/renderer is picked.
|
|
|
|
|
|
|
|
|
