Commits on Source (28)
-
Marius Vlad authored
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 8a1849db)
c8d638b3 -
Marius Vlad authored
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 f3ad5939)
52c924ad -
Marius Vlad authored
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 f3221832)
a08be338 -
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 wayland/weston#446 Signed-off-by: Robert Mader <robert.mader@collabora.com> (cherry picked from commit 933290e6)
673943d7 -
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 dc3b3493)
2fa690a9 -
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 #426 Signed-off-by: Robert Mader <robert.mader@collabora.com> (cherry picked from commit 8b04534c)
7c30ab2d -
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 c83f0a15)
7818b054 -
Signed-off-by: James Le Cuirot <chewi@gentoo.org> (cherry picked from commit 89587db3)
a40ae688 -
Marius Vlad authored
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 d3ed2eb3)
e4522507 -
Marius Vlad authored
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 bd831407) 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>
8df487e0 -
Marius Vlad authored
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 9cf60284)
e34bb982 -
Marius Vlad authored
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 be5b6f9c)
1d95c099 -
Marius Vlad authored
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 c41cdcab)
8c9dff01 -
Marius Vlad authored
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 d03f0137)
975e03b8 -
Marius Vlad authored
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 299f87f0)
41864644 -
Marius Vlad authored
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 ab42159b)
ec999796 -
Marius Vlad authored
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 01ef3746)
b58344b2 -
Marius Vlad authored
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 cc877d4b)
a158b435 -
Marius Vlad authored
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 c15699b7)
870abb15 -
Marius Vlad authored
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 0277046a)
ac83c29e -
Marius Vlad authored
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 054aaa5a)
f573612d -
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 7724c5ea)
d2d5c666 -
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 46a6b5b4)
89c965eb -
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 3e6ef529)
f5d5114d -
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 26698535)
7b390f1d -
And add it to the list of failures triggering a resend of dmabuf feedback scanout tranches. Closes wayland/weston#614 Signed-off-by: Robert Mader <robert.mader@collabora.com> (cherry picked from commit 29d48081)
35c6a4b8 -
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 34f7e01c)
01af0e4e -
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 53a221cc)
f7c5fa17
825 B
887 B
825 B
858 B
857 B