We seem to be using at least mesa 21.1.1 since Weston 10, but we never
explicitly asked for it.
Fixes: #790
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit 0713ea7ee6216e45ebdb67cef63bcef7961d1d4e)
We need only check that the region is not empty. If either the input region or
the constraint region have degenerate extents, the intersection from the
previous instruction will set confine_region->data to pixman_region_empty_data.
Fixes: b6423e59
Signed-off-by: Sergio Gómez <sergio.g.delreal@gmail.com>
(cherry picked from commit 1ed88f60c0125988cf1d952f0dabf568bfd82a13)
Since the logic of pointer constraints assumes a valid view throughout, add a
signal to disable constraints when its current view is unmapped by Weston.
The assumption that a previously unmapped view is valid already leads to the
constraints code crashing. This can happen when attaching a NULL buffer to the
surface and commiting, which effectively unmaps the view with the side effect of
clearing the surface's input region, which is then assumed valid inside
maybe_warp_confined_pointer().
Fixes: #721
Signed-off-by: Sergio Gómez <sergio.g.delreal@gmail.com>
(cherry picked from commit e3079393c400e3dc6498234d1d092f3072fa8b44)
Currently, the surface destroy listener in pointer constraints is redundant,
since surface destruction already handles pointer constraints destruction (see
libweston/compositor.c:weston_surface_unref()).
Signed-off-by: Sergio Gómez <sergio.g.delreal@gmail.com>
(cherry picked from commit 64da736d37a7df8b3bd6fd43746ac513bae72748)
We have no guarantee that we can create a surface for the pointer at the
instant we receive a seat that will (probably eventually) need one.
Hold off until we receive an enter event before creating this - at that
point we know with certainty that wl_compositor is available, since we've
used it to create the surface that was entered.
Fixes#659
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
(cherry picked from commit 11ba13d717)
We want atomic hotspot updates - this can't happen with
wl_pointer_set_cursor. So if we have a surface that already has a cursor
role, just update the hotspot when attaching new content.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
(cherry picked from commit 646cc1b389)
This reverts commit 992ee045f1.
Recreating the surface for every cursor change causes flickering
cursors on some compositors, and is not the best way to achieve
atomic cursor updates
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
(cherry picked from commit ebbe30df3c)
This reverts commit f079f43658.
This only partially fixed a problem introduced in
992ee045f1
I'm reverting that commit in favor of a different fix, so this
broken fix needs to go first.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
(cherry picked from commit 8b0125d601)
Everywhere else where use this trick, we also have 'used' in the
attributes, except here. Make this consistent.
Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/517
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
(cherry picked from commit 5ba7ae2937)
It doesn't need to be using desktop-shell; trying to use it is not
sensible as it will try to bind to all the devices we're repeatedly
creating and destroying, sometimes lose the race, and fail the test
because desktop-shell has died too early.
Signed-off-by: Daniel Stone <daniels@collabora.com>
(cherry picked from commit ed97387a4e)
This has somehow stopped working. Copied different syntax from a gitlab
example.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
(cherry picked from commit 0f4b411091)
When color management is disabled, the fragment shader was still first
ensuring straight alpha and then immediately just going back to
pre-multiplied. This is near-impossible for a shader compiler to
optimize out, I guess because of the if-statement to handle division by
zero. Having view alpha applied in between certainly didn't make it
easier.
That causes extra fragment computations that are unnecessary. In the
issue report this was found to cause a notable performance regression.
Fix the performance regression by introducing special-case paths for
when straight alpha is not needed. This skips the unnecessary
computations.
Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/623
Fixes: 9a6a4e7032
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
(cherry picked from commit 6234cb98d1)
Dropped SHADER_COLOR_MAPPING_IDENTITY as that is not available in weston
10.0.
Unconditionally creating a surface feedback for each surface
creates unnecessary overhead and noise in the logs. Thus
create it when the first surface feedback resource for a
surface is requested and delete it again once all those
resources have been destroyed.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
(cherry picked from commit 53a221ccaa)
Weston uses a timeout of 2 seconds before it sends scanout
tranches to clients in order to not trigger excessive buffer
reallocations in clients.
`simple-dmabuf-feedback` in turn counts redraws (200) before
exiting. That doesn't work on e.g. 144Hz screens, thus use a
timer here as well.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
(cherry picked from commit 34f7e01c2b)
Using `pixel_format_get_info()` can result in formats being
reported as `UNKNOWN` when used on compositors other than Weston.
As `weston-simple-dmabuf-feedback` somewhat succeeds `wayland-info`
as tool for `zwp_linux_dmabuf_v1` debugging from version 4 on, copy
the approach from the later for these cases.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
(cherry picked from commit 2669853562)
In certain situations these clients crash a lot due to the low
buffer limit. Four buffers is also what EGL allows without blocking
and what is arguably the upper limit of what a compositor should
demand.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
(cherry picked from commit 3e6ef529f8)
Compositors may choose to send multiple scanout or non-scanout
tranches. So instead of assuming that the first respective tranche
contains the format/modifier we're looking for, check all tranches.
While on it, make sure that in case a compositor sends scanout
tranches on the initial feedback, `pick_format_from_scanout_tranche()`
does not unintentionally pick `INITIAL_BUFFER_FORMAT`.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
(cherry picked from commit 46a6b5b448)
This fixes an issue when running simple-dmabuf-feedback:
"wl_display@1: error 1: invalid arguments for wl_surface@3.attach".
As we are not using create_immed request from zwp_linux_dmabuf_v1, we
can't start to use a dma-buf buffer before we process compositor's event
telling us that the creation succeeded.
This was causing problems in the following scenario:
1. buffer is marked to be recreated (because of dma-buf feedback);
2. in buffer_release() event, we destroy the buffer and recreate it;
3. after we recreate it, roundtrip is not called, as we don't want to
block during the drawing loop;
4. buffer status is not being properly tracked, so we are trying to
use a buffer before receiving the event from the compositor telling
us that the creation succeeded.
To fix this, this patch improves buffer status tracking. Now we only
pick a buffer in the drawing loop when it is available. Also, if we have
no buffers available we perform a roundtrip and try again, as we may
have recreated all of them but still didn't have the chance to process
compositor's events telling us that creation succeeded.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
(cherry picked from commit 7724c5ea38)
Rather than setting the fullscreen/maximized before initial
wl_surface.commit, make it part of the initial window state.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Pekka Paalanen <pekka.paalanen@collabora.com>
(cherry picked from commit 054aaa5a8b)
Rather than creating the wl_egl_window at the same time as wl_surface,
do it after we get the first configure event.
With it, we also defer eglMakeCurrent() as according to the spec, the
first time a OpenGL or OpenGL ES context is made current, the viewport
and scissor dimensions are set to the size of the draw surface.
This is particulary important when attempting to start simple-egl either
as fullscreen or as maximized, as not doing so will either incorrectly
commit a buffer with the original dimensions, and later on to resize to
the correct dimensions (which is the case for fullscreen), or it will
terminate the wayland connection abruptly due to xdg-shell protocol
violation, with a mismatch for the client's geometry (the case for
maximized).
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
(cherry picked from commit 0277046a1d)
display->wm_base is checked right after handling registry object, and
with it the globals, so there's no to perform and additional check for
xwm_base.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit c15699b7f8)
A previous patch modified this for fullscreen, but missed out the
maximized state. As we check the geometry rather than the buffer
dimensions use the same terminology.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit cc877d4b77)
Just like start as fullscreen, let us add a start as maximized as well.
It tests out the maximized state and with clients geometry checks.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit 01ef3746a2)
This fixes the following weston_view leak at compositor shutdown:
#0 0x7f4250247987 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7f424fd37aa3 in zalloc ../include/libweston/zalloc.h:38
#2 0x7f424fd3a05f in weston_view_create ../libweston/compositor.c:386
#3 0x7f423be7be6a in weston_desktop_surface_create_desktop_view ../libweston-desktop/surface.c:364
#4 0x7f423be7c0a8 in weston_desktop_surface_create_view ../libweston-desktop/surface.c:404
#5 0x7f423beae91d in desktop_surface_added ../desktop-shell/shell.c:2273
#6 0x7f423be77db1 in weston_desktop_api_surface_added ../libweston-desktop/libweston-desktop.c:138
#7 0x7f423be80c73 in weston_desktop_xdg_toplevel_ensure_added ../libweston-desktop/xdg-shell.c:362
#8 0x7f423be8207a in weston_desktop_xdg_toplevel_committed ../libweston-desktop/xdg-shell.c:697
#9 0x7f423be84d45 in weston_desktop_xdg_surface_committed ../libweston-desktop/xdg-shell.c:1374
#10 0x7f423be7b382 in weston_desktop_surface_surface_committed ../libweston-desktop/surface.c:174
#11 0x7f424fd378a6 in wl_signal_emit /home/mvlad/install-amd64/include/wayland-server-core.h:481
#12 0x7f424fd510e2 in weston_surface_commit_state ../libweston/compositor.c:4062
#13 0x7f424fd51161 in weston_surface_commit ../libweston/compositor.c:4068
#14 0x7f424fd516ef in surface_commit ../libweston/compositor.c:4146
#15 0x7f424fb597e9 (/usr/lib/x86_64-linux-gnu/libffi.so.8+0x77e9)
With commit 'libweston, desktop-shell: Add a wrapper for weston_surface
reference' we've removed an explicit weston_view_destroy() call due to a
UAF which would've happen if we had close animations enabled, upon
terminating a client. In that patch I've incorrectly wrote this happened
when animations are off, but in fact it happened when they're on, see the
following trace:
READ of size 8 at 0x616000026498 thread T0
#0 0x7f757fba8797 in weston_signal_emit_mutable ../shared/signal.c:52
#1 0x7f757fb4bba1 in weston_view_destroy ../libweston/compositor.c:2269
#2 0x7f756bca89c0 in desktop_shell_destroy_surface ../desktop-shell/shell.c:275
#3 0x7f756bcb379e in fade_out_done_idle_cb ../desktop-shell/shell.c:2228
#4 0x7f757faec1da in wl_event_loop_dispatch_idle ../src/event-loop.c:969
#5 0x7f757faec31d in wl_event_loop_dispatch ../src/event-loop.c:1032
#6 0x7f757faea114 in wl_display_run ../src/wayland-server.c:1408
#7 0x7f757ff777ba in wet_main ../compositor/main.c:3589
#8 0x55f765c8d17d in main ../compositor/executable.c:33
#9 0x7f757fd997fc in __libc_start_main ../csu/libc-start.c:332
#10 0x55f765c8d099 in _start (/home/mvlad/install-amd64/bin/weston+0x1099)
0x616000026498 is located 24 bytes inside of 608-byte region [0x616000026480,0x6160000266e0)
freed by thread T0 here:
#0 0x7f758004c4d7 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127
#1 0x7f757fb4bdc8 in weston_view_destroy ../libweston/compositor.c:2295
#2 0x7f757fb4c14d in weston_surface_unref ../libweston/compositor.c:2334
#3 0x7f756bca898b in desktop_shell_destroy_surface ../desktop-shell/shell.c:273
#4 0x7f756bcb379e in fade_out_done_idle_cb ../desktop-shell/shell.c:2228
#5 0x7f757faec1da in wl_event_loop_dispatch_idle ../src/event-loop.c:969
This patch re-introduces it to avoid leaking the view upon compositor
shutdown, but it does it in tandem with weston_desktop_surface_unlink_view(),
(which was added in a later patch) and before weston_surface_unref() call.
This way we should be safe to terminate/close clients with additional views
created by libweston-desktop (pop-ups), but also in other different situations.
Verified it in the following circumstances:
- terminating a client with close animation on
- terminating a client with close animations off
- shutting down the compositor with clients running, with and
without close animations
- terminating top-level clients with additional pop-ups with both with
and without close animations
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit ab42159bf3)
This documents the fact that other views are handled implictly by
libweston-desktop, and we shouldn't attempt to destroy indiscriminately
views that aren't created by desktop-shell.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit 299f87f073)
This patch fixes the following trace:
#0 0x7f07d1bcecfa in weston_desktop_surface_get_surface ../libweston-desktop/surface.c:585
#1 0x7f07d1bfc9b8 in move_grab_motion ../desktop-shell/shell.c:1499
#2 0x7f07e539f841 in notify_motion ../libweston/input.c:1794
#3 0x7f07e1e8ace4 in handle_pointer_motion ../libweston/libinput-device.c:132
#4 0x7f07e1e8cad5 in evdev_device_process_event ../libweston/libinput-device.c:535
#5 0x7f07e1e89311 in udev_input_process_event ../libweston/libinput-seat.c:208
#6 0x7f07e1e8932f in process_event ../libweston/libinput-seat.c:218
#7 0x7f07e1e8935f in process_events ../libweston/libinput-seat.c:228
#8 0x7f07e1e8940a in udev_input_dispatch ../libweston/libinput-seat.c:239
#9 0x7f07e1e89437 in libinput_source_dispatch ../libweston/libinput-seat.c:249
#10 0x7f07e53122b1 in wl_event_loop_dispatch ../src/event-loop.c:1027
#11 0x7f07e5310114 in wl_display_run ../src/wayland-server.c:1408
#12 0x7f07e579c7ba in wet_main ../compositor/main.c:3589
#13 0x555611d6b17d in main ../compositor/executable.c:33
#14 0x7f07e55be7fc in __libc_start_main ../csu/libc-start.c:332
#15 0x555611d6b099 in _start (/home/mvlad/install-amd64/bin/weston+0x1099)
A highly unlikely, but still valid operation, is to close/destroy the
window while still having it grabbed and moved around, basically having
an in-flight destruction of grabbed moving window. Another situation
would be that the client terminates abruptly (crashing for instance),
while being dragged which might take down the compositor.
This could happen for both touch/pointer grab operations and could cause
a NULL pointer access while accessing desktop_surface when being used
to retrieve the underlying weston_surface.
With this patch we check for a valid desktop_surface and return early
if that's not the case.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit d03f01377a)
Moving weston_desktop_surface_unlink_view() to
desktop_shell_destroy_surface() makes sure we don't leak the underlying
weston_desktop_view when tearing/shutting down the compositor.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit c41cdcabb4)
No functional change. Makes it obvious that we also call
weston_layer_fini().
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit be5b6f9cdc)
Creates a distinct view, separated from the one created by
libweston-desktop, in order to avoid a potential ownership fight with
libweston-desktop upon destroying the view. Upon weston_desktop_surface
destruction, libweston-desktop inflicts damage on the view it creates,
so we need the view to be alive at that time.
This wasn't such an issue before because we had different destruction paths but
with commit 'desktop-shell: Do not leave views in layers upon shell
destruction' all of the destruction paths now land in the same spot
+ handle compositor tear down.
Note as we still use the same weston_surface we'll keep the previous
construct where we were taking a reference to keep it alive.
The original view is destroyed when releasing the ownership, while for
the view created in this patch we handle the destruction directly upon
compositor tear down.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit 9cf602840d)
Similar to how we do it with drm_fb ref counts, increase a reference
count and return the same object.
Plug-in in desktop-shell when we map up the view in order to survive a
weston_surface destruction.
Astute readers will notice that this patch removes weston_view_destroy()
while keeping the balance between removing and adding a
weston_surface_unref() call in desktop_shell_destroy_surface().
The reason is to let weston_surface_unref() handle destruction on its
own. If multiple references are taken, then weston_surface_unref()
doesn't destroy the view, it just decreases the reference, with
a latter call to weston_surface_unref() to determine if the view
should be destroyed as well. This situation happens if we have
close animation enabled, were we have more than one reference taken: one
when mapping the view/surface and when when the surface itself was created,
(what we call, a weak reference).
If only a single reference is taken (for instance if we don't have close
animations enabled) then this weston_surface_unref()
call is inert as that reference is not set-up, leaving libweston to
handle the view destruction.
Following that with a weston_view_destroy() explicit call would cause a
UAF as the view was previous destroyed by a weston_surface_unref() call.
A side-effect of not keeping the weston_view_destroy() call would
happen when tearing down the compositor. If close animations are enabled,
weston_surface_unref() would not destroy the view, and because
weston_view_destroy() no longer exists, we would still have the
view in the other layers by the time we check-up if layers
have views present.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit bd8314078d)
While the original patch was adding a weston_surface_ref() wrapper, this
patch doesn't add any wrapper to avoid a minor version bump, but instead
achieves a similar outcome by inlining the wrapper version being added
by the original commit.
Further more, as the original patch was dependent on another patch,
any mention of weston_surface_unref() in the commit description
should instead be replaced with weston_surface_destroy().
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Calling weston_surface_destroy() one time too many could be a sign we
haven't correctly increased the ref count for it.
Also, if we don't have a surface being passed, do no attempt to
use it.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit d3ed2eb345)
Test different scenarios where child subsurfaces of unmapped
subsurfaces would get mapped. This test will fail in various
ways without the commit
"libweston/compositor: Do not map subsurfaces without buffer"
Also try to test potential regressions of that patch.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
(cherry picked from commit c83f0a1539)
We can end in `subsurface_committed()` in different scenarios
without the surface having an attached buffer. While setting
the mapped state to `true` in that case doesn't matter for
that (sub)surface itself, it triggers its own child subsurfaces
to get mapped when they shouldn't.
Closes https://gitlab.freedesktop.org/wayland/weston/-/issues/426
Signed-off-by: Robert Mader <robert.mader@collabora.com>
(cherry picked from commit 8b04534c76)
Changing `wl_surface_damage()` to `wl_surface_damage_buffer()`
should not have an effect on the existing tests.
The new test will fail without the commit
"libweston/compositor: Cache buffer damage for synced subsurfaces"
Signed-off-by: Robert Mader <robert.mader@collabora.com>
(cherry picked from commit dc3b349325)
The spec states:
> Because buffer transformation changes and damage requests may be
> interleaved in the protocol stream, it is impossible to determine
> the actual mapping between surface and buffer damage until
> wl_surface.commit time. Therefore, compositors wishing to take both
> kinds of damage into account will have to accumulate damage from the
> two requests separately and only transform from one to the other after
> receiving the wl_surface.commit.
For subsurfaces in sync mode, arguably the same is the case until the
cached state gets applied eventually. Thus, in order to keep complexity
to a sane level, just accumulate buffer damage and convert it only
when the cached state gets applied.
This mirrors how other compositors like Mutter implement cached damage
and what the spec arguably should demand.
Closes https://gitlab.freedesktop.org/wayland/weston/-/issues/446
Signed-off-by: Robert Mader <robert.mader@collabora.com>
(cherry picked from commit 933290e6ea)
In multiple output cases, finding the succesor from the inactive layer
might result in picking the wrong view when there are multiple views
being stacked in the inactive layer. This adds two additional checks to
favor views on the same output as the one being destroyed/removed.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit f3221832c5)
This adds an additional check to make sure the current focus surface
is on the same output as the surface that is going to be activated.
This is necessary in order to avoid placing the currently focused one in
the inactive layer, which shouldn't happen in situations where the new
surface is going to be placed on a different output than the currently
focused one.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit f3ad593925)
Some applications would set-up the app_id after the initial commit
(without a buffer) which is too late to correctly assign the application
to the corresponding output set-up in the configuration file.
This patch fixes that by checking one more time, after a buffer has been
attached, if indeed there's an output with an app_id set.
Fixes: #469
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit 8a1849db8a)
Nikita Tokarchuk
Marius Vlad
Sergio Gómez
Derek Foreman
Simon Ser
Pekka Paalanen
Daniel Stone
Robert Mader
Leandro Ribeiro
James Le Cuirot
Kenny Levinsen