Currently Xwayland is cleaned up by a destroy listener. The problem with
this is that this is true for both libweston's Xwayland support as well
as the frontend's.
Add an explicit destroy step to Xwayland frontend which will cleanly
destroy the process as well as any other resources.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Return a void * from wet_load_xwayland, so we can later pass it back to
explicitly call the cleanup.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Make sure that we consistently mark the client as NULL when it's
destroyed, and destroy it on process exit as well, so we have a
consistent state.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We rely on the Xwayland launcher setting $DISPLAY to connect to our own
X server. Make very sure in the tests that we're actually getting that
set properly.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Remove all handling of process/PID internals from libweston's Xwayland
launcher, and keep this only in the frontend. libweston now only sees
the wl_client and nothing else.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Every time we call wet_client_launch, we now allocate a new wet_process,
which is always cleaned up by the compositor core and not by the users.
In doing this, weston_client_launch is renamed to wet_client_launch,
since wet_ is for the frontend and weston_ is for libweston.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Instead of reusing an inline wet_process struct, allocate a new
wet_process every time we go to launch Xwayland.
Signed-off-by: Daniel Stone <daniels@collabora.com>
wet_process provides a cleanup function which can be called, but only
passes the process itself. This relies on the process struct being
inlined in something else meaningful, and means that we can't allocate
them on demand.
Add a 'data' argument which allows users to pass meaningful data to
their cleanup handler.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Bookworm has just been released. Add jobs which start using it, but keep
bullseye around as the LTS release, to make sure we can build on new and
old distributions.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Debian bookworm needs a newer version of Mesa to build against LLVM 15.
Upgrade Mesa and the kernel whilst we're at it, just to make sure that
things keep working.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Newer versions of Debian make you pass --break-system-packages to pip in
order for it to install packages. Since we do want to keep using pip for
controlled versions rather than the distribution packages, add this
flag.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Until now we've only had the unadorned arithmetic functions, but they're
easy to abuse and tedious to use.
For now, we just add weston_coord_global_add/sub functions and use them
where appropriate.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This is stored as an unadorned weston_coord internally, but with getter
functions we can put together the appropriate global or surface
coordinate.
Use them where appropriate.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Truncating a weston coord to integer values is something we do
frequently enough to warrant a helper function.
Use this in the kiosk and desktop shells where appropriate.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Let the GL renderer render to FBOs for RDP outputs and read the pixels
into the RDP frame buffer. This allows to run the RDP backend with the
GL renderer.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Add switch statements where renderer specific API is called to prepare
for adding GL renderer support. No functional change.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Partially revert commit 89e1831cd7 ("pixman-renderer: add
weston_renderbuffer and create/destroy interface") to bring back the
shadow_surface pixman image. The renderbuffer is only wrapped around it.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
The 'confine' client is used to showcase the behavior of pointer confinement
through the interface zwp_confined_pointer_v1.
Since zwp_confined_pointer_v1 is part of pointer constraints in general, which
includes pointer locking, it makes sense to augment the scope of the client so
it can serve as a showcase for this category of interfaces through
zwp_pointer_constraints_v1.
Currently 'confine' relies on, and is designed around the limitations of, the
toytoolkit. Adapting the toytoolkit for the new requirements proved
unproductive, especially since we wish to add support for pointer constraints in
sub-surfaces. Hence the solution adopted was to write a new client that would
replace the previous one.
This patch introduces the new client, 'constraints.c', replacing 'confine.c'.
Signed-off-by: Sergio Gómez <sergio.g.delreal@gmail.com>
We need this so that Weston can update the "click to activate" serial, so
that we can then use the constraints protocol (see
maybe_enable_pointer_constraint() in libweston/input.c).
Signed-off-by: Sergio Gómez <sergio.g.delreal@gmail.com>
Translate damage extents used to calculate glReadPixels rectangle from
global to local coordinates.
Fixes: b1606a9f2c ("gl-renderer: support automatically downloading FBO renderbuffers")
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
When an output is moved, all views that are not moving with it should
cause damage where they appear in it before and after the move, and all
prior damage should move with the output.
To avoid this complexity, just damage the full output after the move.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
This is similar to commit 'libweston: Update view transforms more often', where
we update the view's transform when getting the panel dimensions.
Fixes#740
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Track damage on struct weston_renderbuffer and drop the custom damage
region from struct wayland_shm_buffer.
Pass repaint damage to wl_surface_damage() instead of accumulated
renderbuffer damage.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
While the GL renderer is not able to directly render into the PipeWire buffers,
it is possible to read the rendered frame from the fbo into the PipeWire buffer.
Use the automatic download to add support for the GL renderer to the PipeWire
backend.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Instead of always initializing the Pixman renderer, make the initialization
dependent on the selected renderer. This makes it easier to add other renderers.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Make it easier to understand where ptr points to by using local variables for
the spa_buffer and spa_data.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Extract the pixman renderbuffer configuration from the add_buffer function into
a helper function to simplify the addition of the GL renderer.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Use helper function for setting up the pixman renderer to simplify the addition
of the GL renderer.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>