| Age | Commit message (Collapse) | Author |
|---|
|
This new API allows buffer implementations to know when a user is
actively accessing the buffer's underlying storage. This is
important for the upcoming client-backed wlr_buffer implementation.
|
|
Prior to this commit, subsurfaces could only be placed above their
parent. Any place_{above,below} request involving the parent would
fail with a protocol error.
However the Wayland protocol allows using the parent surface in the
place_{above,below} requests, and allows subsurfaces to be placed
below their parent.
Weston's implementation adds a dummy wl_list node in the subsurface
list. However this is potentially dangerous: iterating the list
requires making sure the dummy wl_list node is checked for, otherwise
memory corruption will happen.
Instead, split the list in two: one for subsurfaces above the parent,
the other for subsurfaces below.
Tested with wleird's subsurfaces demo client.
Closes: https://github.com/swaywm/wlroots/issues/1865
|
|
Rename the xdg_popup_get_position to
wlr_xdg_popup_get_position
|
|
There isn't always a good time to prune old tokens. Compositors
which only implement a "give focus on activation" logic can prune
tokens on focus change. However other compositors might want to
implement other semantics, e.g. "mark urgent on activation". In this
case a focus change shouldn't invalidate other tokens.
Additionally, some tokens aren't necessarily tied to a seat.
To avoid ending up with an ever-growing list of tokens, add a timeout.
|
|
This implements the new xdg-activation-v1 protocol [1].
[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/50
|
|
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 was always set to ARGB8888.
|
|
|
|
|
|
This allows compositors to choose a wlr_buffer to render to. This
is a less awkward interface than having to call bind_buffer() before
and after begin() and end().
Closes: https://github.com/swaywm/wlroots/issues/2618
|
|
This allows users to know the capabilities of the buffers that
will be allocated. The buffer capability is important to
know when negotiating buffer formats.
|
|
This property is present on all modern X11 instances. The nonpresence of
it requires applications to fall back to XQueryTree-based logic to
determine stacking logic (e.g., to determine what surface should get
Xdnd events).
These code paths are effectively untested nowadays, so this makes it
more likely for wlroots to "break" applications. For instance, the
XQueryTree fallback path has been broken in Chromium for the last 10
years.
It's easy enough to maintain this property, so let's just do it.
Fixes #2889.
|
|
When importing a DMA-BUF wlr_buffer as a wlr_texture, the GLES2
renderer caches the result, in case the buffer is used for texturing
again in the future. When the wlr_texture is destroyed by the caller,
the wlr_buffer is unref'ed, but the wlr_gles2_texture is kept around.
This is fine because wlr_gles2_texture listens for wlr_buffer's destroy
event to avoid any use-after-free.
However, with this logic wlr_texture_destroy doesn't "really" destroy
the wlr_gles2_texture. It just decrements the wlr_buffer ref'count.
Each wlr_texture_destroy call must have a matching prior
wlr_texture_create_from_buffer call or the ref'counting will go south.
Wehn destroying the renderer, we don't want to decrement any wlr_buffer
ref'count. Instead, we want to go through any cached wlr_gles2_texture
and destroy our GL state. So instead of calling wlr_texture_destroy, we
need to call our internal gles2_texture_destroy function.
Closes: https://github.com/swaywm/wlroots/issues/2941
|
|
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.
|
|
|
|
|
|
|
