Commits on Source (15)
-
Marius Vlad authoredThis re-orders the disable/destroy shutdown sequence such that lookup_remoted_output(), in remoting_output_disable(), would find a remoting output. Otherwise, without this, lookup_remoted_output() wouldn't find a remoting output available when shutting down the compositor, ultimately leading to a crash. Signed-off-by:
Marius Vlad <marius.vlad@collabora.com> (cherry picked from commit c3270e88)
0ba5b694 -
Marius Vlad authored
With commit aab722bb, "backend-drm: prepare virtual output API for heterogeneous outputs", we now call the virtual destroy function, but when shutting the compositor we no longer have a remoting instance available. When searching out for a remoting output verify if the remoting instance is still available before attempting to search for a remoting output. Addresses the following crash at shutdown: 0x00007fd430a1d347 in lookup_remoted_output (output=0x557163d5dad0) at ../remoting/remoting-plugin.c:515 0x00007fd430a1d746 in remoting_output_destroy (output=0x557163d5dad0) at ../remoting/remoting-plugin.c:635 0x00007fd439e11ab9 in drm_virtual_output_destroy (base=0x557163d5dad0) at ../libweston/backend-drm/drm-virtual.c:265 0x00007fd43a8635d0 in weston_compositor_shutdown (ec=0x557163239530) at ../libweston/compositor.c:8271 0x00007fd439e029d4 in drm_destroy (backend=0x557163240ae0) at ../libweston/backend-drm/drm.c:2713 0x00007fd43a863e07 in weston_compositor_destroy (compositor=0x557163239530) at ../libweston/compositor.c:8626 Includes a note to point up what should be done about by checking out #591 . Fixes aab722bb "backend-drm: prepare virtual output API for heterogeneous outputs" Signed-off-by:
17f5a44f -
Marius Vlad authored
Similarily to what the remoting plug-in does, explicitly call weston_release_head() before removing the output list entry. We do that to avoid lookup_pipewire_output() returning NULL and still find out the pipewire_output. Signed-off-by:
eaa777b9 -
Marius Vlad authored
This happens when shutting the compositor, and follows-up with the remoting plug-in. Signed-off-by:
597437a0 -
Marius Vlad authored
Seems like we are missing destroying the pipewire outputs on the shutdown path; this follow-ups with remoting plug-in as well. Signed-off-by:
0849a9b3 -
Marius Vlad authored
Similarly to remoting plug-in in commit "Check virtual outputs/remoting instance" this avoids touching the pipewire instance, and with it, the pipewire output. Includes a note to point up what should be done about by checking out #591 . Signed-off-by:
70479268 -
Marius Vlad authored
Starting with commit 4cde507b "backend-drm: fix plane sorting" the plane list will have a descending order of the planes rather than ascending. This reversed order had the side-effect of exposing the fact that we don't set-up a plane index when creating the drm_plane using the DRM virtual API. Without settting a plane index for that drm_plane we effectively overwrite the plane index which has the 0 (zero) entry. This wasn't an issue before commit 4cde507b "backend-drm: fix plane sorting" as it seems we never picked up that plane index as being a suitable one due to the fact that those were assigned to primary planes, but after that commit, the cursor plane will be one getting the 0 (zero) plane index. Finally, this would trip over because we attempt to place a (cursor) view on a primary plane (where it would've normally be a cursor plane) and we end up with no framebuffer ref. This is fixed trivially by assigning a plane index, different than the ones already created by create_spirtes(). Signed-off-by:
df70b81e -
During interactive resizes, we progressively change the size of the client surface and send config events with these sizes to the client. After that, the toplevel->pending.size keeps the size of the last config event that we've sent, i.e. the surface size after the resize is over. Later, if the client spontaneously resize (by attaching a buffer with a different size or setting the viewport destination, for instance), their surface size will change, but toplevel->pending.size continues being that old size from after the resize. If something happens and Weston decides to send a config event, clients may re-allocate to that old size, resulting in a sudden resize. This does not happen when a client goes from fullscreen/maximized to windowed mode because in such cases we are resetting toplevel->pending.size to zero. So in the next config event that clients receive they are allowed to attach buffers with the size that they prefer. So do the same after a resize: set the pending config size to zero. Signed-off-by:
Leandro Ribeiro <leandro.ribeiro@collabora.com> (cherry picked from commit ba82af93)
d5a3ec5e -
A config event with width == 0 or height == 0 from the shell is a hint to the client to choose its own dimensions. Since X11 clients don't support such hints we make a best guess by trying to use the last saved dimensions or, as a fallback, the current dimensions. This hint is mainly used by libweston/desktop shells when transitioning to a normal state from maximized, fullscreen or after a resize [1]. Without support for this hint the aforementioned transition causes xwayland surfaces to be configured to a 1x1 size. To be able to use the last saved dimensions with xwayland surface, the shell needs to first set the maximized/fullscreen state and only then set the new size, which is currently the case for desktop-shell. Otherwise, if the new size is set first, then the last saved dimensions will be set to the fullscreen/maximized values and won't be useful when restoring to a normal window size. [1] Recently we've introduced ba82af93 "desktop-shell: do not forget to reset pending config size after resizes". As we were not handling the 0x0 size hint, resizing X applications started to fail. This patch fixes that. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com> Signed-off-by:
2d66d01c -
When a view is destroyed then the views of subsurfaces remain until the view list is rebuilt for the next repaint. During that time view->parent_view contains an invalid pointer and weston will crash when it tries to access the view. This happens for a surface with subsurfaces with views on two different outputs with the ivi-shell: When the surface is destroyed then the destroy handler of the ivi-shell (shell_handle_surface_destroy()) may be called first. It will (indirectly) destroy the view of the main surface with weston_view_destroy(). Next the surface destroy handler of the subsurfaces (subsurface_handle_parent_destroy() is called. It will unmap the first view of the subsurface. Here weston_surface_assign_output() is called which tries to find the output of the second view and accesses the now invalid view->parent_view in the process. There are probably other ways to trigger similar crashes. To avoid this, clear view->parent_view when the parent view is destroyed. Fixes 0669d4de ("libweston: Skip views without a layer assignment in output_mask calculations") Signed-off-by:
Michael Olbrich <m.olbrich@pengutronix.de> (cherry picked from commit 39796f88)
5ad870f5 -
The desktop_surface object is destroyed first so it can happen that the shsurf still exists but desktop_surface is already NULL. So expand the check to make sure the desktop_surface is still available in the resize callbacks. Signed-off-by:
ff13a90e -
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 64da736d)
0bd68d9a -
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:
21e46364 -
Signed-off-by:
072c5672 -
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:
a627a4be
