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>
Align the function name and arguments of vnc_convert_damage() with
weston_region_global_to_output(). It does not support rotation and
stores the result in a pixman_region16_t, but otherwise it serves the
same purpose.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
I also snuck in a trivial change to drag_surface_configure at the same
time to avoid yet another micro patch.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
weston_renderer::repaint_output must be called from the weston_output::repaint
callback. When called from the weston_output::enable callback, a black frame
is produced. Instead of painting an invalid buffer and then working around it
by setting output damage, just don't skip the first real repaint even though
no VNC client is connected yet.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Add a debug scope "vnc-backend" and use it to log per-renderbuffer
accumulated damage and new repaint damage before repainting.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Since neatvnc frame buffers are in system memory, using a shadow
buffer just causes an unnecessary copy in the pixman renderer.
Stop using the shadow buffer.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
It is enough to report new repaint damage instead of accumulated
per-renderbuffer damage to nvnc_display_feed_buffer().
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
While not repainting, all buffers are damaged exactly the same.
Avoid unnecessary work by tracking this damage separately on struct
vnc_output.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
When compositor is active, we cannot make sure that the output power
state is normal, if the output power was forced off, there is nothing can
display on the output. Therefore, only do fade animations when the output
power state is normal
Signed-off-by: Vinh Nguyen Trong <Vinh.NguyenTrong@vn.bosch.com>
In IVI, there are several displays connected to a SoC. These displays
are just driven by differential pairs (LVDS, FPD-Link, GMSL) and powered
centrally. To reduce power comsumption when user inactivity timeout
happended on the display, there is a need to cut down pixel clock from
SoC. Then, if any input events happend on the display, it should become
active again.
Currently, controlling the compositor outputs doesn't happen independently
but rather globally, and outputs repaints are based on the compositor state
This is necessary to have an API that can force the power state of an
output to off via DPMS mode while all other compositor outputs remain
unaffected.
Signed-off-by: Rajendraprasad K J <KarammelJayakumar.Rajendraprasad@in.bosch.com>
Signed-off-by: Vinh Nguyen Trong <Vinh.NguyenTrong@vn.bosch.com>
It turns out we no longer have stdout/stderr in CI for the
tests. As 1.0.0 is the latest stable version for meson use that
to bring back our test messages.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
For pango_cairo_font_map_set_default().
Fixes#720
Suggested-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
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>
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>
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>
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>
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>
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>
This is needed by drm_output_fini_egl() to be able to retrieve the
backend out of the drm_output on the shutdown path of the compositor.
Both the remoting plug-in and the pipewire plug-in are users of the
drm-virtual API and as such they would trigger a crash when shutting
down the compositor, as we're not setting up any backend whatsoever.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Convert the bare x,y coordinates into struct weston_coord and update all
users.
We keep the surface position in wl_fixed_t for now so it still exactly
matches the position most recently sent to clients.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
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>
The pixel format stored in backends->format[0] is effectively looked up
via pixel_format_get_info(DRM_FORMAT_ARGB8888). Reuse that instead of
looking up the same via pixel_format_get_info_by_pixman(PIXMAN_a8r8g8b8)
in multiple places.
There are still two instances of hard-coded CAIRO_FORMAT_ARGB32 in
wayland_output_get_shm_buffer() that currently can not be obtained from
pixel_format_info.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
When a dependency path is converted to string and dependency is a
subproject, then accessing such file fails in meson with:
ERROR: Sandbox violation: Tried to grab file ... from a nested subproject.
Use '/' operator as documented in
https://mesonbuild.com/Dependencies.html#dependencies-that-provide-resource-filesFixes: #715
Signed-off-by: Vasyl Vavrychuk <vvavrychuk@gmail.com>
This reverts commit 4eea291512.
There were some details and cases that I've missed when writing this
commit, resulting in some weird behaviors. Trying to cover all of them
became a nightmare, and the function got really hard to read.
So it's better to revert this commit and think about other possible
solutions for the issue.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
If the wl_surface resource has version 5 or newer, we should always
ignore the offset parameters in wl_surface.attach.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
ivi-shell has allowed to notify a surface configuring when detecting
an unmapping commit. To avoid the commit_change with source_width
and source_height are zero, we should don't do a configuring when
surface has no content.
Signed-off-by: Tran Ba Khang(MS/EMC31-XC) <Khang.TranBa@vn.bosch.com>
If a client commits a null buffer, weston will unmap all the views of
the surface and marks it is unmapping. In the case, the client commits
a new valid buffer, then the controller wants to rebuild the views
without applies the pending properties of surfaces and layers.
The ivi_layout_interface should prodive an interface for this.
Suggested-by: Michael Olbrich's avatarMichael Olbrich <m.olbrich@pengutronix.de>
Suggested-by: K J Rajendraprasad's avatarRajendraprasad K J <KarammelJayakumar.Rajendraprasad@in.bosch.com>
Signed-off-by: Tran Ba Khang(MS/EMC31-XC) <Khang.TranBa@vn.bosch.com>
Push weston_coord into the notification functions instead of passing
two doubles.
The touch handlers are passed a pointer to a weston_coord, which is
unusual. This is done so we can pass a NULL pointer instead of a
fabricated invalid coordinate when the touch type is TOUCH_UP.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Wayland protocol can't do this, but the way our test protocol handles
touch through a single event can - ensure that we don't by accident.
This will matter more shortly when we add assert()s to prevent having
coordinates with WL_TOUCH_UP events internally later.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
