The surface argument is only used to obtain a wlr_seat_client and
semantically makes no sense. The wl_touch.cancel event applies to all
touch points and all surfaces of a client.
I decided to make the functions accept a wlr_seat_client rather than a
wl_client as it is directly available in the wlr_touch_point struct and
simplifies the implementation.
This is worth doing despite wl_client_get_destroy_listener() incorrectly
accepting a mutable wl_client pointer since this lookup_client()
function will primarily be used with a wl_display_global_filter_func_t
which only provides a const wl_client pointer.
Work around this libwayland API wart in wlroots so compositors don't
have to.
I wish to use a allowlist of globals for my security context
implementation rather than a blocklist, which means I need access to
the wp_single_pixel_buffer_manager_v1 global in order to allowlist it.
I think using a allowlist will make it harder for me to accidentally
expose globals to a security context that were meant to be restricted.
I wish to use a allowlist of globals for my security context
implementation rather than a blocklist, which means I need access to
the ext_idle_notifier_v1 global in order to allowlist it.
I think using a allowlist will make it harder for me to accidentally
expose globals to a security context that were meant to be restricted.
I wish to use a allowlist of globals for my security context
implementation rather than a blocklist, which means I need access to
the wl_shm global in order to allowlist it.
I think using a allowlist will make it harder for me to accidentally
expose globals to a security context that were meant to be restricted.
This new helper assists compositors in allocating buffers for
modesets. It degrades to different allocation parameters as
needed, and should help with screens not turning on when multiple
outputs are connected on some hardware (e.g. Intel).
For simplicity, the old logic to try allocating with explicit
modifiers first and then fallback to implicit modifiers later is
left as-is. We'll probably want to have more complicated logic
instead in the future: try the fallback on one output at a time,
and try dropping modifiers one by one instead of using implicit
modifiers (at the cost of some combinatorial explosion).
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/1873
Co-authored-by: Kenny Levinsen <kl@kl.wtf>
This centralizes logic common for both the atomic and libliftoff
backends. Additionally, a struct will make it easier to implement
multi-connector commits (since it can be stored in an array).
This allows us to remove the renderer destroy listener. The
listener was buggy: compositors can't destroy surface resources on
their own.
The wlr_compositor will always outlive the wlr_surface, so no need
for a destroy listener.
Use the same logic for cursor FBs as we currently use for primary
FBs. This also fixes the same bug as [1] but in a different, more
robust way.
The new logic integrates better with atomic and will be required
anyways in the future when set_cursor will be superseded by a better
API.
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4577
Saving the old context and immediately making our own context
current is a common pattern. Let's make it easier to do.
No functional change, just refactoring.
For XWayland surfaces that start maximized, it's best to send an initial
Configure event to set the size of the surface before mapping it. This
reduces visual glitches since the application sees the correct maximized
size when performing its initial layout and drawing.
wlroots surfaces emit their first "map" event after the XWayland window
has already been mapped and the first frame has been drawn & committed.
This is too late to send the initial Configure event.
So, add a new "map_request" event which is emitted immediately before
telling XWayland to map the window. Compositors can connect to this
event to send the initial Configure event to an XWayland app based on
its requested maximized (or fullscreen) state.
Compositors should not place anything visually on the screen at this
point but rather wait until the "map" event as before.
On startup, we fetch the previous MODE_ID blob ID so that
compositors can keep using the previous mode if they want to.
However, that blob doesn't belong to us, it belongs to the
previous DRM master. As a result, we get an error when trying to
destroy it.
Fix this by tracking whether the blob belongs to us or not.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3811