Some VNC clients, i.e. noVNC, do not support TLS encryption.
Add new argument "--disable-transport-layer-security" to
explicitly disable activation of TLS.
This will allow to extend VNC clients compatibility.
Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
Similar to the VNC backend do the same for the RDP backed, as this would
allow to get a matching output, in dimensions, to the one we are
mirroring.
This also re-works a bit the no-clients-resize to be more inline with
VNC one.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This would allow to screen-share a particular output like the
following:
[output]
name=vnc
same-as=DP-5
[output]
name=rdp-0
same-as=DP-4
[output]
name=pipewire
same-as=eDP-1
Both 'vnc', 'pipewire' 'rdp-0' remote outputs would then be a
screen-share 'DP-5', respectively, 'e-DP1', or the 'DP-4' DRM output.
Currently, this is intended only for VNC, RDP and PipeWire remote outputs.
This patch exports weston_output_set_position(), and uses that for
overlapping a remote output with a native DRM one, rather than using
weston_output_move() as that has a side-effect when reflowing outputs
from shells.
Further more creating this remote output is driven entirely by compositor
signal events such that enabling an DRM native output would enable the
remote output, while disabling the native would have the same outcome
for the remote one.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This avoids dereferencing a possible stale pointer, and allows
retrieving the modeline/refresh later on when one needs to retrieve
those values. This is a temporary band-aid.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
The main differences is the split of cm_surface functionality with
cm_surface and cm_feedback_surface.
There can only be one cm_surface to set, unset image descriptions. When
cm_surface is destroyed, the image description is automatically unset.
There can be multiple feedback_surfaces for one surface though.
Now the "preferred_changed" signal can be an initial event.
Creator params now have a new request: set_luminances.
Signed-off-by: Joan Torres <joan.torres@suse.com>
This new public API is intended to deliver EDID etc. information to the
frontend. The use case here is display colorimetry, to help the frontend
craft output image descriptions (color profiles).
The frontend will need to link to and use libdisplay-info to make use of
this. This avoids having to replicate in libweston the high-level API
that libdisplay-info already has. The libdisplay-info API is also likely
to be extended, and it is not nice to play catch-up with it.
As a di_info can only be destroyed by calling into libdisplay-info,
libweston core can only ensure it has already been freed. There is not
enough reason to make libweston core depend on libdisplay-info, only the
DRM-backend is.
It will be up to DRM-backend to ensure display_info is updated and
device_changed is set only when necessary.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We've got output->scale, output->current_scale, output->original_scale and
output->native_scale.
output->scale is apparently just a weird temporary variable, and has led
to some confusing bugs.
Remove it entirely.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Fundamentally, the flags are a property of each paint node, rather than
each view as such. Move them over there so it gets a little less painful
to work with.
Signed-off-by: Daniel Stone <daniels@collabora.com>
After c08a6ff8 moved attach to the render loop, we have a bad situation
when clients delete an attached shm buffer. We try to query the stride
at attach time, but the shm_buffer has been destroyed, and we crash.
Instead of carefully fixing that, I've instead stored the stride at
buffer creation time (as we already do with buffer width and height).
This lets attach succeed in the gl-renderer, keeping the old texture data
available for any upcoming rendering.
Fixes: #927
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Tested-by: Connor Abbott <cwabbott0@gmail.com>
Currently only the return value of the last backend that implements
repaint_flush() is actually used. That only works because the drm backend is the
only backend that implements repaint_flush().
In the drm backend only the return value of the last device is used. And if a
failure is actually detected, then all repainted outputs of all backends are
reset. This can trigger asserts:
weston_output_schedule_repaint_reset() (or _restart()) will change the state of
the output but the backend that did not cause the failure will still call
weston_output_finish_frame().
The same thing can happen with multiple devices in the drm backend. Or outputs
get stuck if an error is dropped.
Since the drm backend is the only one that implements repaint_flush() anyways,
move the failure handling into the backend and make it device specific.
This way only the outputs that need it are reset.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
When a repaint is triggered then not all backends may have outputs that need to
be repainted.
Check which outputs will be repainted first and then repaint only the backends
that need it.
This way unnecessary repaint_begin() and repaint_flush()/repaint_cancel() can
be skipped and errors are handled for each backend separately.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Add API to create color profiles from parameters. It is a public API
that should be used by the frontend and also by the color management
protocol implementation.
Currently our protocol implementation does not support clients that want
to create color profiles from parameters, and this is a step towards
supporting that.
As warned in "color: add get_color_profile_from_params() to color
managers", we still do not fully support creating color profiles from
parameters. This just creates a boilerplate color profile that we're
planning to extend later.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Up to now we had support only for transfer functions with pre-defined
parameters in struct weston_color_tf_info. Add support for the first
parameterized transfer function (a function whose params are not
pre-defined).
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In the next commits we are going to introduce a public API to libweston
to allow creating color profiles from parameters. This should be used
by both the frontend and by the color protocol implementation.
This API require some color struct's and enum's that are currently
defined in libweston core, so move them to a public header.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Such that shells can retrieve Xwayland's surface WM_CLASS/WM_NAME and use
it to place the corresponding Xwayland surface on the appropriate
output, similar to what xdg_shell::set_app_id does.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
There are no longer users of these two function. With the
weston_view_move_to_layer() helper being capable of doing this it is time
to retire these entirely to avoid users using them.
Release notes should mention that migrating to the newer helper will be
required when bumping to Weston 14.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This API is mostly for use by the DRM-backend. Colorimetry mode is is
the KMS connector property "Colorspace" which defines the video signal
encoding colorimetry. A video sink indicates the supported modes in EDID
or DisplayID.
This patch adds the libweston API that allows backends to indicate the
supported modes for the frontends, and frontends to set the mode to be
used by backends. Colorimetry mode does not directly affect color
management inside Weston, it is only metadata for the video sink. It is
the frontend's responsibility to set up an output color profile that
agrees with the colorimetry mode. (That API has not been implemented
yet.) eotf_mode will be the same.
There is only one reason to make this a libweston core API instead of
a backend-drm API: when wayland-backend gains color-management protocol
support, meaning it can forward WCG and HDR content correctly to a
host compositor, the supported colorimetry modes can be determined from
the host compositor's supported color-management features, allowing the
guest Weston to pick some other output image description than the host
compositor's preferred image description. This likely allows only a few
other choices from standard colorspaces, so it's possible this isn't
sufficient for that use case.
Either way, it is easy to just copy the eotf_mode API design, and since
colorimetry_mode and eotf_mode go together, let both have the same API
design. It is possible to convert this to backend-drm API later.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Turns out these structures do not need to be in the public header, so
move them into a private header.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Just like with color profiles, generate an ID for color transformations
as well. This is not needed by protocol or anything, it is just for
debugging purposes. A small ID is easier for humans than a long pointer
value.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The windowed output API is implemented by the Wayland, the X11 and the
headless backends. It's currently not possible to create a secondary
headless backend when the primary backend is Wayland or X11 because
the windowed output API would be registered twice. This commit
suffixes the windowed output API names with the backend name in order
to avoid clashes: "weston_windowed_output_api_<backend>_v2".
A use case for Wayland or X11 as primary backend and headless as
secondary is for instance to request output captures on the headless
backend to avoid read backs on the primary backend's render buffers.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Damages and captures both trigger repaints of outputs. Some
configurations don't care about damages and use headless only for
captures. This commit adds a new feature to libweston that lets
outputs repaint only on captures, not on damages. The headless backend
enables that new feature when given a special refresh rate of 0 mHz.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Custom headless refresh rates can be useful to instrument clients
matching different screen configurations. This commit adds support for
that to the headless backend and exposes it to the frontend with the
"--refresh-rate" CLI option. The default refresh value is still 60 Hz.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
In this MR we add support to the majority of the interfaces from the
color-management protocol.
That means that we are able to advertise output's images descriptions to
clients, preferred surface images descriptions, and so on. We also
support clients that wants to create ICC-based images descriptions and
set such descriptions for surfaces.
We still don't support the interface to allow clients to create
image descriptions from parameters, but that should be addressed
in the near future.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This is preparation for the CM&HDR protocol implementation. It requires
us to give a unique id to each color-profile, so let's do that.
In this commit we introduce a generic id generator to libweston, and
its first user: the color-profile.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Currently we flush damage for the "primary plane" every repaint, but this
is folly.
The drm backend may skip rendering entirely if using an all-planes
composition. This could leave the renderer plane in a messy state if a
surface on an overlay plane disappears.
Instead, let the backends flush the primary plane damage when they know
they need to render.
Fixes#864
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
And with it, bump libweston to next major version, 14. We seems like
we never used that argument so better just removed it.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Ignore any client-supplied offset to subsurface commits to keep the same
consistency we find on other compositor.
Fix: #829
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
If coverage and power status are the same, we should prefer a primary
backend over a secondary one.
Fixes#818
Signed-off-by: Derek Foreman <derek.foreman@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>
The counterpart to weston_surface_is_unmapping(). This is valid for the
duration of processing the surface commit.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We already have these for global coordinates, now we have them for
surface coordinates too. In addition to removing some unsightly
unadorned coordinate usage, this also adds appropriate coordinate space
id checks at runtime.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This is a tricky bit of code and we use it in two places. Let's make a
single implementation.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This avoids spreading around the knowledge that the primary backend is
the first backend on weston_compositor::backend:list.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.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>
Before loading a backend, clear the weston_compositor::backend pointer
to check whether the backend supports multi-backend operation and adds
itself to the weston_compositor::backend_list.
Keep weston_compositor::backend pointing to the last loaded backend
either way, to allow the calling compositor code to store it away for
later, to check whether a head belongs to a given backend in the output
configuration code. This workaround can be removed after all backends
are converted to be multi-backend aware.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
In preparation for multi-backend support, add a list of backends to the
weston_compositor structure. Until backends are converted, this list
just contains the single weston_compositor::backend. Keep that pointer
for now, until the conversion is complete.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Most of these don't use the parameter that changes at all, but some get
a nice simplification.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
There are many times when we want to set a global position with a surface
offset added.
It's a fairly nasty operation, and most places in the code currently do
it naively, ignoring the painful existence of freeform window rotations
and other complex transforms that could be in play (but probably aren't)
Add a helper for this and convert existing usage.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Simple helper to multiply a surface coordinate by -1, -1. There are no
uses yet, but will be in a follow up patch that wants to have cursor
hotspots in their inverted form.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
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>
The function find_focus_successor() is called when destroying a surface to find
a successor to the current focus. It, however, has the following issues:
- Its first parameter is the weston layer from which to search for a successor.
This is an unnecessary flexibility for our use, which only adds complexity to
the user of the function by having to make a call for each layer. We know
that we want to search for a successor first in the normal layer, and if that
fails, then in the inactive layer. So we change the signature of
find_focus_successor(), removing this first parameter.
- It includes logic to decide whether to do the search or not: if the destroyed
surface is different from the surface that currently has focus, and if their
outputs are the same, then abort and don't do the search. This returns NULL to
the calling function. The problem is that the function also returns NULL if
it does the search and finds no successor. The distinction for the failing
reason is lost, and the user of the function needs to add more logic to know
the reason for failure. To simplify, we take the logic out of
find_focus_successor() and inside the caller.
- It returns the successor view, although it receives surfaces and the client
has logic to retrieve the surface corresponding to the returned view. To
simplify and maintain symmetry, we change the signature so that the function
returns the surface corresponding to the successor view.
Fixes: #738
Signed-off-by: Sergio Gómez <sergio.g.delreal@gmail.com>
Lukasz Czechowski