Similar to what we have to all other backends/outputs, do the same
for the remoting/pipewire plug-ins and align them to the right.
This way we can move the plug-ins loading after
weston_compositor_flush_heads_changed(), much closer to the other module
loading which seems a more suitable place.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Rather than loading the plug-ins when loading the DRM backend, do that
after *all* the other backends have been loaded, and after we made sure
we have at least a no-op color manager.
As the plug-ins enable the outputs on their own this has the side-effect
of enabling the output without having any color manager set-up at that
time. Moving the plug-in loading a bit later ensures that we have one
set-up (a no-op one).
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
In some use cases the VNC client should not be allowed to resize the VNC
output. Add a boolean option "resizeable" in the VNC [output] section to
control this.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Document the --additional-devices parameter to Weston to add secondary
DRM devices that will only be used as outputs, but not for rendering.
Fixes: 3c6cfe6bf4 ("backend-drm: add additional-devices to support multi GPU")
Signed-off-by: Marek Vasut <marex@denx.de>
Let weston_compositor_load_backend() return a backend pointer and remove
the backend pointer from struct weston_compositor.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Add a new --backends command line option and a backends option to the
configuration file that both take a comma-separated list of backends,
similar to the modules option.
The first backend is the primary backend and provides the renderer.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
When multiple backends are loaded simultaneously, they all have
to register their own head change notification listener and
output configuration callback.
To avoid calling output configuration for heads created by other
backends, only iterate over heads that were created from the given
backend by comparing the weston_head::backend pointer to the one
stored in the head change notification listener.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Let backends declare the presentation clocks they can use with a
new bitfield weston_backend::supported_presentation_clocks and set
presentation clock after loading the backend in the compositor.
Make weston_compositor_set_presentation_clock() internal and replace
weston_compositor_set_presentation_clock_software() with an exported
weston_compositor_backends_loaded(), which is called by the compositor
after the backend is loaded.
In the future, this can be extended to determine the subset of clocks
supported by all backends.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Add another wrapper so we can build with -Dxwayland=false.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: 388702c181 ("frontend: Explicitly destroy Xwayland from frontend code")
Closes: wayland/weston#779
Add tls-cert and tls-key config options in the [rdp] and [vnc] sections
in weston.ini. This allows to statically configure the TLS key and
certificate files instead of requiring them to be supplied via command
line arguments.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
On a desktop system, the expected behavior during a Weston start is that if any
monitor can be enabled, Weston starts up and enables the monitor. Outputs that
could not be enabled, stay disabled. This helps the user in debugging the failed
outputs.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
If Weston fails to configure a DRM output for whatever reason, it will fail to
start. Depending on the use-case, this may or may not be the correct behavior.
Add the "require-outputs" option to allow configuring the error behavior on
missing outputs.
Add documentation of the possible options to the man page.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
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>
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>
Hardcode the ad hoc EDID parser to always claim that only SDR is
supported. Even though libdisplay-info is not yet asked for HDR
capabilities, it shall be the only way to see them.
To be nicer to experimenters, main.c adds a note that you really need
libdisplay-info if you want to play with HDR.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Now that our process-launching internals are identical between the
(still-misnamed) weston_client_launch and the frontend's Xwayland
launcher, we can reuse the internals instead of open-coding it.
As a result, we now additionally prevent Xwayland from inheriting
Weston's signal mask, by clearing SIG_UNBLOCK on all signals. This
should have no observable effect as we do not depend on signal handling
within Xwayland, instead using the displayfd readiness mechanism since
c2f4201ed2.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This gets us closer to the implementation of weston_client_launch, so we
can reuse that instead of open-coding it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
weston_client_start() takes only a single path with no arguments,
forking a process to start that command line, and creating a client from
it.
weston_client_launch(), which was always misnamed and will be renamed in
the next patch, now only handles the child process and nothing else.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When we launch a child, we need to clear CLOEXEC on any FDs we want to
survive the exec. Use an array for doing this, so it's more generic and
we can allow callers to pass in their own.
Signed-off-by: Daniel Stone <daniels@collabora.com>
See discussion in wayland/weston!951 for the reasoning why: the
screenshooter must only deal with wl_client.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When we're asked to take a screenshot but are already taking one, just
exit out of the function early.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Add a separate PipeWire backend based on the PipeWire plugin. The backend
requires PipeWire 0.3.x.
The PipeWire backend can be used as a standalone-backend backend for streaming
and composing Wayland clients to PipeWire.
The backend supports the on-demand creation of heads via the
weston_pipewire_output_api_v1. It also supports per-output pixel format
configuration via a gbm-format option.
Multiple PipeWire outputs can be created by setting the num-outputs option in
the [pipewire] section.
Co-authored-by: Michael Tretter <m.tretter@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Pass the backend instead of the compositor to the windowed output API
create_head() method and increment the API version.
That way the backend will not have to find the backend pointer from the
compositor. This is trivial now, but in the multi-backend case would
entail iterating over all backends to find the correct one.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Add the --additional-devices parameter to Weston to add secondary drm devices
that will only be used as outputs, but not for rendering.
We can only fail the repaint for the entire backend, but not for single
devices. Thus, if one of the devices fail, we have to fail the repaint for the
entire backend.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
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>
Marius Vlad