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 0713ea7ee6)
The override-redirect window will not be assigned a shell_surface
object. If it is used as a parent window, it will cause a crash
when calling the set_parent function.
The EWMH specification does not describe the behavior of an
override-redirect window as a parent window, so we should ignore
this case.
Signed-off-by: Liu, Kai1 <kai1.liu@intel.com>
(cherry picked from commit b468687dd2)
Currently, if a head is detached, the entire state of the device is invalidated
to make sure that the connector is disabled on the next atomic commit. Side
effect of the invalid state is that all planes are disabled on the next commit.
This includes planes that are used with a different head that is not part of the
next atomic commit. Disabling the planes of unrelated outputs causes a blanking
of these outputs until output is repainted and the plane is reenabled.
Store the detached heads in a list on the output and disable the connectors for
all heads in this list in the next atomic commit.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
(cherry picked from commit bcacd9ec5a)
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 1ed88f60c0)
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 e3079393c4)
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 64da736d37)
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: Michael Olbrich <m.olbrich@pengutronix.de>
(cherry picked from commit 06365e602b)
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 0669d4de4f ("libweston: Skip views without a layer assignment in
output_mask calculations")
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
(cherry picked from commit 39796f88e6)
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 ba82af938a
"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: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Co-authored-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
(cherry picked from commit 2acd2c7489)
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 ba82af938a)
Starting with commit 4cde507be6 "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 4cde507be6 "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: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit 27ce9dadd8)
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 https://gitlab.freedesktop.org/wayland/weston/-/issues/591.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit 6617deebec)
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: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit 278fe4d7d4)
This happens when shutting the compositor, and follows-up with the
remoting plug-in.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit aa78da2465)
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: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit 5db6d19e6b)
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 https://gitlab.freedesktop.org/wayland/weston/-/issues/591.
Fixes aab722bb "backend-drm: prepare virtual output API for
heterogeneous outputs"
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit ca52c79c51)
This 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 c3270e887b)
If we don't xcb_flush() when we set the selection owner, we end up with
a ridiculous corner case where we can run use a command line X client
like 'xclip -i -selection clipboard' to crash weston.
Start weston, ensure Xwayland is running (set a selection with xclip), set
the clipboard from a wayland client, then set the clipboard with xclip
again.
Since xclip doesn't do anything xwm notices except set the clipboard, it
won't provoke a flush on our selection ownership change. xclip will take
ownership, then we call xcb_convert_selection(), and THEN we flush, sending
out our pending ownership change and the xcb_convert_selection() request.
The ownership change takes place first, we attempt to get our own selection
and weston explodes in a mess.
Stop this from happening with a flush when changing selection ownership.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
(cherry picked from commit 11bcad116f)
It's possible to set the clipboard with no seat present - one way is to
use the RDP backend and then run 'xclip -i -selection clipboard' locally
without making an RDP connection.
Check if seat is NULL to prevent this from crashing.
Fixes#698
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
(cherry picked from commit bb993df236)
To avoid the following UAF:
Invalid read of size 8
at 0x4AE5EFF: weston_desktop_get_display (libweston-desktop.c:110)
by 0x4AEB2C9: weston_desktop_xdg_surface_schedule_configure (xdg-shell.c:1160)
by 0x4AEA77A: weston_desktop_xdg_toplevel_set_size (xdg-shell.c:711)
by 0x4AE839D: weston_desktop_surface_set_size (surface.c:504)
by 0x63F7D43: ivi_layout_surface_set_size (ivi-layout.c:1599)
by 0x63F949F: transition_move_resize_view_destroy (ivi-layout-transition.c:311)
by 0x63F9397: layout_transition_destroy (ivi-layout-transition.c:259)
by 0x63F8E0B: ivi_layout_remove_all_surface_transitions (ivi-layout-transition.c:121)
by 0x63F4BC1: ivi_layout_surface_destroy (ivi-layout.c:258)
by 0x63F38AF: layout_surface_cleanup (ivi-shell.c:162)
by 0x63F3D2D: shell_destroy (ivi-shell.c:359)
by 0x4AF059A: weston_signal_emit_mutable (signal.c:62)
Address 0x174202d0 is 0 bytes inside a block of size 152 free'd
at 0x484617B: free (vg_replace_malloc.c:872)
by 0x4AE5EDC: weston_desktop_destroy (libweston-desktop.c:97)
by 0x63F3CF2: shell_destroy (ivi-shell.c:355)
by 0x4AF059A: weston_signal_emit_mutable (signal.c:62)
by 0x4ACBC2C: weston_compositor_destroy (compositor.c:8629)
by 0x4864A4B: wet_main (main.c:3908)
by 0x10915D: main (executable.c:33)
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit eb755cd81a)
Shutting down the compositor gives us:
Invalid write of size 8
at 0x4B1AEDB: wl_list_remove (wayland-util.c:56)
by 0x4AF05BF: weston_signal_emit_mutable (signal.c:66)
by 0x4ACBC2C: weston_compositor_destroy (compositor.c:8629)
by 0x4864A4B: wet_main (main.c:3908)
by 0x10915D: main (executable.c:33)
Address 0x17435f20 is 224 bytes inside a block of size 384 free'd
at 0x484617B: free (vg_replace_malloc.c:872)
by 0x17718C7E: hmi_controller_destroy (hmi-controller.c:761)
by 0x4AF059A: weston_signal_emit_mutable (signal.c:62)
by 0x4ACBC2C: weston_compositor_destroy (compositor.c:8629)
by 0x4864A4B: wet_main (main.c:3908)
by 0x10915D: main (executable.c:33)
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit cfbf2b0ab2)
The ivi-shell keeps track of its surfaces by adding them to the ivi_surface_list
to be able to remove them on shutdown. It also creates an ivi_layout_surface for
a desktop surface, but does not keep track of these surfaces.
During compositor shutdown, libweston prints the following message:
BUG: finalizing a layer with views still on it.
Fix it by adding the created ivi_layout_surface to the ivi_surface_list to
remove the surfaces from the layer during shutdown.
Furthermore, remove the ivi_layout_surface from the desktop surface and free it
when the desktop surface is destroyed.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
(cherry picked from commit 266e2e1d48)
Resolved small conflict which arose due to commit cbf476f208.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
If a controller requests the layers under a surface that has no views attached,
Weston crashes since it tries to free the array that would be used to return the
found layers, but has not been allocated before.
Free the ppArray only if it was allocated in ivi_layout_get_layers_under_surface
before and no layers were found.
While at it, make it obvious that checking the length is an integer comparison
by comparing it to 0.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
(cherry picked from commit c56e69bc85)
The activation of a view implies, among other things, a change in the
associated view layer which is initially unset. In order for this change
to be reflected in the corresponding surface's output mask, and hence
allow surface damage to trigger output repaints, we need to update the
view transform.
Fixes#674
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
(cherry picked from commit 341d09d232)
This adds a destroy listener on the SHM buffer provided by our client.
It will unregister the frame notify listener in case our buffer is
destroyed before the frame signal is emitted and thus avoid a memcpy
to invalid memory.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
(cherry picked from commit 0afd3428dc)
Currently we can't tell the difference between a window intentionally
created at 0,0 and a window that we can place anywhere.
Check the size hints to see if the flags indicating the placement
is intentional are present.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
(cherry picked from commit 1cb46994e3)
Fixes the following warnings when building with _FORTIFY_SOURCE
and optimizations enabled:
../shared/xalloc.h:49:9: error: ignoring return value of ‘write’ declared with attribute ‘warn_unused_result’ [-Werror=unused-result]
49 | write(STDERR_FILENO, oommsg, strlen(oommsg));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
or
../compositor/main.c:427:25: error: ignoring return value of ‘write’ declared with attribute ‘warn_unused_result’ [-Werror=unused-result]
427 | write(STDERR_FILENO, fail_seteuid,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
428 | strlen(fail_seteuid));
| ~~~~~~~~~~~~~~~~~~~~~
../compositor/main.c:434:25: error: ignoring return value of ‘write’ declared with attribute ‘warn_unused_result’ [-Werror=unused-result]
434 | write(STDERR_FILENO, fail_cloexec,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
435 | strlen(fail_cloexec));
| ~~~~~~~~~~~~~~~~~~~~~
../compositor/main.c:442:25: error: ignoring return value of ‘write’ declared with attribute ‘warn_unused_result’ [-Werror=unused-result]
442 | write(STDERR_FILENO, fail_exec, strlen(fail_exec));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit 8c4cdd782e)
As clipboard_find_supported_format_by_mime_type() can return -1 if it
can't find out an index avoid trying to print outside of the array.
Fixes the following warnings triggered when enabling FORTIFY_SOURCE
combined with optimizations (-O)
../libweston/backend-rdp/rdpclip.c:1114:17: error: array subscript -1 is below array bounds of ‘uint32_t[5]’ {aka ‘unsigned int[5]’} [-Werror=array-bounds]
1114 | weston_log("RDP %s (%p:%s) specified format \"%s\" index:%d formatId:%d is not supported by client\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1115 | __func__, source, clipboard_data_source_state_to_string(source),
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1116 | mime_type, index, source->client_format_id_table[index]);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../libweston/backend-rdp/rdpclip.c:131:18: note: while referencing ‘client_format_id_table’
131 | uint32_t client_format_id_table[RDP_NUM_CLIPBOARD_FORMATS];
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit 9455ad7c7c)
As seen previous times, with newer doxygen version we seem to be
generating warnings and with it to stop generating documentation
entirely as we have enabled warning as error in the doxygen
configuration file.
By default meson werror build option is not enabled, so users can still
generate documentation when building regularly, and when we'll update to
the same doxygen version we should be able to catch those errors up if
any of them will pile up in between.
Suggested-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
(cherry picked from commit 402d9a81c9)
As things are, even when mode=current is specified on the .ini file,
a full modeset is needed (and done), which causes a very noticeable
screen blinking. That is because setting the max_bpc on a connector
needs full modesetting.
The idea here is that if mode=current on the .ini, no modesetting
should be done, so the current max_bpc is programmed into the
connector.
But if a custom max-bpc=... is specified, that will be used instead,
even if mode=current on the .ini
Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/660
Signed-off-by: vanfanel <redwindwanderer@gmail.com>
(cherry picked from commit 3240ccc69d)
Currently the frame event gets lost: The touch focus is removed in the 'up'
event. So the focus is gone when the frame event arrives so it is never sent to
the clients.
To avoid this, keep the touch focus until the frame is handled.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
(cherry picked from commit 5448580111)
This has undergone a change to avoid an ABI break, so rather than
hooking up a pending_touch boolean in weston_touch, keep a local list of
weston_touch_devices and have a pending_touch with each device to check
upon.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Surface views that are not assigned to a layer are not going to be
rendered, and thus should not participate in determining the outputs the
surface is on.
There are other view properties that may determine if the view should be
considered in output_mask calculations, e.g., is_mapped, but checking
for this currently breaks tests. Such additional checks are left for
future fixes or reworkings of the view infrastructure.
Fixes#646
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
All these Doxygen configuration directives raise a deprecation warning
with Doxygen 1.9.5.
Since we have WARN_AS_ERROR = YES, this causes the build to fail.
Remove these deprecated directives.
I have checked the differences by first building from scratch without
this patch, and then building from scratch with this patch, and
in the latter builddir checking
$ diff -ru -x '*.md5' -x '*.pdf' ~/tmp/weston-doc-before doc
The only differences are the Doxygen config file and one .pickle file.
So it seems the generated docs are identical with Doxygen 1.9.1.
Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/661
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
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>
Tracking correctly previous events shouldn't corrupt the surface destroy
signal list. This enforces that by ensuring that we wouldn't have
a .notify wl_listener still being set (which shouldn't happen if we do
eventually get a focus_in event that clears it out).
Suggested-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Rather than doing it with a local variable, track any previous events by
hanging it out of the x11 backend and use it to handle keymap notify
events.
In this way we avoid corrupting the surface destroy signal list, in
notify_keyboard_focus_out(), ultimately leading to a crash.
Fixes#649, #650
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
Reported-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
The planes in the plane_list must be sorted from largest zpos_max to smallest.
Currently the plane order is only correct when the planes are already ordered
and added starting with the smallest zpos_max. This works accidentally in most
cases because the primary plane is usually first and there is often only one
overlay plane or the zpos is sufficiantly configurable.
To fix this, insert a new plane before the first plane with a smaller zpos_max.
And if none is found, insert it at the end of the list.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
With commit 62ab6891db, 'clients/simple-egl: Handle buffer
scale and transform' we changed the way we resized the client, by
encapsulating the resize in update_buffer_geometry() function.
we didn't correct that when creating the EGL window, which might be
problematic if you attempt to start the window with different a
different state, like maximized.
Fixes 62ab6891db
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
If weston-simple-egl is run with the "-b" flag, it will attempt to set
the swap interval to 0 during create_surface. However, at that point, it
will not have made its EGLContext current yet, causing the
eglSwapInterval call to have no effect. To fix this, wait until the
EGLContext has been made current in init_gl before updating the swap
interval.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Marius Vlad