We're always passing pointer->x, y converted to surface coordinates, or
garbage if view is NULL. Let's just stop passing those coordinates
entirely and calculate them in the function.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This adds basic VNC protocol support using the Neat VNC library
(https://github.com/any1/neatvnc). Neat VNC depends on the AML main
loop library. The backend makes use of AML's integrated epoll backend
and connects AML via file descriptor with the Wayland event loop.
This implementation does not support authentication and hardcodes the
pixel format currently.
Co-authored-by: Philipp Zabel <p.zabel@pengutronix.de>
Co-authored-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
Signed-off-by: Stefan Agner <stefan@agner.ch>
[r.czerwinski@pengutronix.de:
- use new (as of 0.5.0) Neat VNC buffer API, with a buffer pool]
Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
[p.zabel@pengutronix.de:
- transform repaint damage to output coordinates
- transform pointer coordinates into global space
- check that outputs and heads are in fact ours, see aab722bb1785..060ef82d9360
- track damage across multiple frame buffers
- choose pixel format by drm_fourcc, see 8b6c3fe0ad
- enable ctrl and alt modifiers
- fix frame timing to achieve a constant repaint rate
- pass initial size explicitly, see f4559b0760
- use resize_output with pixman-renderer, see 55d08f9634e8..84b5d0eb4bee
- allow configuring the refresh rate]
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
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>
This is arguably a little nicer without calling the pixman functions
directly.
In the future when we have different datatypes for coordinates in different
spaces, this test will only be valid on global coordinates, so this change
is also a precursor to stronger type validation.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This was actually introduced as part of desktop zoom. We no longer have
use of it.
This makes a subtle functional change - the output's matrices will now be
up to date immediately in cases where previously that update could have
been deferred.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Except the module dir path, they're one and the same. This change
warrants a libweston version bump, if it hasn't been done already.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
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>
With commit 'Move libweston-desktop into libweston' we've moved out
libweston-desktop DSO into libweston. Move also the header to
libweston/desktop.
This removes removes the libweston-desktop pc file and bumps libweston
major version to 12.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Everywhere we are standardising to drm_fourcc.h pixel format codes, and
using struct pixel_format_info as a general handle that allows us to
access the equivalent format in various APIs. In the name of
standardisation, convert weston_compositor::read_format to
pixel_format_info.
Pixman formats are defined CPU-endian, while DRM formats are defined
always little-endian. OpenGL has various definitions. Correctly mapping
between these when the CPU is big-endian is an extra chore we can
hopefully offload to pixel-formats.c.
GL-renderer read_format is still defined based on Pixman format, because
of the pecualiar way OpenGL defines a pixel format with
GL_UNSIGNED_BYTE. That matches the same Pixman format on big-endian but
not the same drm_fourcc.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This allows for setting a buffer offset without having to make it part
of the wl_surface.attach request. This is useful for e.g. setting a DND
surface icon hotspot offset when using Vulkan; or doing the same with
EGL without having to use wl_egl_window_resize().
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
This protocol allows clients to create single-pixel RGBA buffers. Now
that we have proper support for these buffers internally within Weston,
we can expose them to clients.
This bumps the build container version, as we now depend on
wayland-protocols v1.26.
Signed-off-by: Daniel Stone <daniels@collabora.com>
weston_compositor_reflow_outputs() assumes that all output are positioned from
left to right with no gaps in the same order in which they where created.
If the shell moves an output with weston_output_move() then this assumption is
no longer true. So stop reflowing the outputs in the case. The shell is now
responsible for positioning all outputs as needed.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
If a surface or a view is not mapped, then we should not be trying to
paint it. Check if this is the case and ensure that we only insert
paint nodes for mapped surfaces & views.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: #621
"max bpc" property is meant for working around faulty sink hardware.
Normally it should be set to the maximum possible value so that the
kernel driver has full freedom to choose the link bpc without being
artificially forced to lower color precision.
The default value is 16 because that is a nice round number and more
than any link technology I've heard is using today which would be 12.
Also offer an API set the value, so that weston.ini could be used in the
next patch for sink workaround purposes.
Closes: https://gitlab.freedesktop.org/wayland/weston/-/issues/612
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Add a struct weston_head parameter to weston_compositor_create_output()
and fold weston_compositor_create_output_with_head() into it.
See: https://gitlab.freedesktop.org/wayland/weston/-/issues/268
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Stop plugins from overwriting the struct weston_output::destroy vfunc,
as that will be used by backends to recognize their outputs.
Instead, pass a plugin-specific destroy callback when creating the
virtual output.
See: https://gitlab.freedesktop.org/wayland/weston/-/issues/268
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
As a first step towards heterogeneous outputs, add an opaque pointer
weston_head::backend_id that will be used by backends to identify
their own heads.
See: https://gitlab.freedesktop.org/wayland/weston/-/issues/268
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
This #define was used only by the matrix-test program, which was removed
in the previous commit.
Remove it as unused and fold away MATRIX_TEST_EXPORT.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Output color profile may be changed in flight. Output basic color
characteristics and EOTF mode cannot yet be changed in flight, but it is
reasonable to assume they could in the future. Therefore the color
outcome data may change in flight as well, which is the basis for HDR
metadata, which needs to be updated as well.
Track the changes to color outcome data with a serial number.
DRM-backend checks the serial number to see if it needs to re-create the
HDR metadata blob. This allows the changes to propagate all the way to
KMS.
The code added here is more of a reminder of what should happen than a
tested path.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This adds hdr_meta field in weston_output_color_outcome. This field is
intended to be set by color manager modules, and read by backends which
will send the information to the video sink in SMPTE ST 2084 mode a.k.a
Perceptual Quantizer HDR system.
Such metadata is essential in ST 2084 mode for the video sink to produce
a good picture.
The validation of the data and the group split is based on the HDR
Static Metata Type 1 definition in CTA-861-G specification.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This adds color_chracteristics field in weston_output. This field is
intended to be set by compositor frontends and read by color managers.
Color managers can use this information when choosing the output color
space and dynamic range, particularly when no ICC profile has been set.
This is most useful for HDR outputs, where the HDR static metadata for
PQ mode or the display luminance parameters for HLG mode can be based on
color_characteristics.
The fields of weston_color_characteristics mirror the information
available in EDID. However, using EDID information as-is has several
caveats, so the decision to use EDID for this is left for the frontend
and ultimately to the end user.
There are no defined ranges or validity checks for this data. The color
manager will have to validate the values against whatever it is using
them for.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Allow the front end to register audio setup and teardown functions. These
functions should use FreeRDP's rdpsnd_server_context or
audin_server_context and set up their own handler threads.
The backend remains mostly ignorant to any audio details beyond setting up
and tearing down.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Introduce a renderer_private hook for weston_buffer, and use this to
store a copy of the gl_buffer_state for EGL buffers (i.e. non-dmabuf, via
EGL_WL_bind_wayland_display).
As part of this, we create the EGLImage along with the weston_buffer
information, and just take a reference to it each time it is attached.
If you have bisected a failure to update surface content to this commit,
it very likely means that your EGL implementation requires images to be
recreated rather than only rebound in order to have their content
updated, which is contrary to specification.
Signed-off-by: Daniel Stone <daniels@collabora.com>
No-one should be implementing an external renderer, so move the
interface out of the public header.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Similar to how we do it with drm_fb ref counts, increase a reference
count and return the same object.
Plug-in in desktop-shell when we map up the view in order to survive a
weston_surface destruction.
Astute readers will notice that this patch removes weston_view_destroy()
while keeping the balance between removing and adding a
weston_surface_unref() call in desktop_shell_destroy_surface().
The reason is to let weston_surface_unref() handle destruction on its
own. If multiple references are taken, then weston_surface_unref()
doesn't destroy the view, it just decreases the reference, with
a latter call to weston_surface_unref() to determine if the view
should be destroyed as well. This situation happens if we have
close animation enabled, were we have more than one reference taken: one
when mapping the view/surface and when when the surface itself was created,
(what we call, a weak reference).
If only a single reference is taken (for instance if we don't have close
animations enabled) then this weston_surface_unref()
call is inert as that reference is not set-up, leaving libweston to
handle the view destruction.
Following that with a weston_view_destroy() explicit call would cause a
UAF as the view was previous destroyed by a weston_surface_unref() call.
A side-effect of not keeping the weston_view_destroy() call would
happen when tearing down the compositor. If close animations are enabled,
weston_surface_unref() would not destroy the view, and because
weston_view_destroy() no longer exists, we would still have the
view in the other layers by the time we check-up if layers
have views present.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Make it obvious that weston_surface has a reference counting happening
and destruction of the weston_surface happens when the last
weston_surface reference has been accounted for.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
I am going to need to add yet another output property to be set by a
color manager: HDR Static Metadata Type 1. With the old color manager
API design, I would have needed to add the fourth function pointer to be
called always in the same group as the previous three. This seemed more
convoluted than it needs to be.
Therefore collapse the three existing function pointers in the API into
just one that is resposible for setting up all three things.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This new struct collects all the things that a color manager needs to
set up when any colorimetry aspect of an output changes. The intention
is to make the color manager API less verbose.
In this first step, the new struct is added and replaces the fields in
weston_output.
The intention is for the following color manager API changes to
dynamically allocate this structure. Unfortunately, until that actually
happens, we need a temporary way to allocate it. That is
weston_output::colorout_, which will be removed in the next patch. This
keeps the patches more palatable for review at the cost of some
back-and-forth in code changes.
This is a pure refactoring, no functional changes.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is the switch to turn HDR mode on.
The values in the enumeration come straight from CTA-861-G standard.
Monitors advertise support for some of the HDR modes in their EDID, and
I am not aware of any other way to detect if a HDR mode actually works
or not. Different monitors may support different and multiple modes.
Different modes may look different. Therefore the high-level choice of
how to drive a HDR video sink is left for the Weston frontend to decide.
All the details like what HDR metadata to use are left for the color
manager.
This commit adds the libweston API for backends to advertise support and
for frontends to choose a mode. Backend and frontend implementations
follow in other commits.
The frontend API does not limit the EOTF mode to the supported ones to
allow experimentation and overriding EDID.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We currently hardcode a 60Hz update rate for the rdp backend.
In some cases it may be useful to override this to increase the rate
for a faster monitor, or to decrease it to reduce network traffic.
Co-authored-by: Steve Pronovost <spronovo@microsoft.com>
Co-authored-by: Brenton DeGeer <brdegeer@microsoft.com>
Signed-off-by: Hideyuki Nagase <hideyukn@microsoft.com>
Signed-off-by: Steve Pronovost <spronovo@microsoft.com>
Signed-off-by: Brenton DeGeer <brdegeer@microsoft.com>
We already have a way for a single RDP client connection to be
passed from a parent process to a child using a combination
of environment variable (RDP_FD) and env var (--env-socket)
This patch allows a bound socket fd (as opposed to a client
connection) to be established in a parent process and provided
to the rdp backend. WSLg uses this to set up an AF_VSOCK
socket for communication between a Windows RDP client and a
weston compositor running under a hypervisor.
Co-authored-by: Hideyuki Nagase <hideyukn@microsoft.com>
Co-authored-by: Steve Pronovost <spronovo@microsoft.com>
Signed-off-by: Hideyuki Nagase <hideyukn@microsoft.com>
Signed-off-by: Steve Pronovost <spronovo@microsoft.com>
Signed-off-by: Brenton DeGeer <brdegeer@microsoft.com>
Rather than punching through to set the surface as a solid colour,
attach an actual weston_buffer to it instead.
This becomes the first user of attaching non-client-generated buffers
to a weston_surface. As a result, it is necessary to introduce a
function which will allow compositors and shells to attach a buffer to a
surface. weston_surface_attach_solid() is therefore introduced as a
special-purpose helper which will attach a solid buffer to a
weston_surface.
It is not intended as a general-purpose mechanism to allow compositors
to attach client-generated buffers to surfaces, as doing so would have
unknown effects on this core part of the compositor itself.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Currently solid-colour displays (e.g. the background for fullscreen
views) is implemented by a special-case weston_surface which has no
buffer attached, with a special punch-through renderer callback to set
the colour.
Replace this with a weston_buffer type explicitly specifying the solid
colour, which helps us eliminate yet more special cases in renderers and
backends.
This is not handled yet in any renderer or backend, however it is also
not used by anything yet. Following commits add support to the renderers
and backends.
Signed-off-by: Daniel Stone <daniels@collabora.com>
In the original conception, a weston_buffer_reference indicated that the
underlying contents of the wl_buffer would or could be accessed, so
wl_buffer.release must not be sent until the last reference was
released, as the compositor may still use it.
This meant that renderers or backends which copied the buffer content -
such as the GL renderer with SHM buffers - could only send a buffer
release event to the client by 'losing' the buffer reference altogether.
The main side effect is that `weston-debug scene-graph` could not show
any information at all about SHM buffers when using the GL renderer, but
it also meant that renderers and backends grew increasingly exotic
structures to cache information about the buffer.
Now that we have an additional buffer-reference mode (still referring to
the weston_buffer/wl_buffer, but not going to access its content), we
can allow the weston_buffer_reference and weston_buffer to live as long
as the buffer itself, even if we do send a release event.
This will enable a bunch of backend and renderer deduplication, as well
as finally making scene-graph more useful.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Add a mode argument to weston_buffer_reference which indicates whether a
buffer's storage may/will be accessed, or whether the underlying storage
will no longer be accessed, e.g. because it has been copied. This will
be used to retain a pointer to the weston_buffer whilst being able to
send a release event to the client.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Keep the weston_buffer alive for as long as at least one of the
underlying wl_buffer or a backend usage exists.
Signed-off-by: Daniel Stone <daniels@collabora.com>
y_inverted meant that the buffer's origin was (0,0), and non-inverted
meant that the buffer's origin was (0,height). In practice, every buffer
was 'inverted' into our natural co-ordinate space that we use
everywhere.
Switch to using an explicit origin enum to make this more clear.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Rather than open-coding various resource -> type accessors, just stick a
type enum in the buffer struct.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Rather than only filling weston_buffer information when we first come to
use it, add an explicit hook so we can fill the dimensions the first
time the buffer's attached.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We already have the buffer in the caller, and every no-op implementation
will want to access the buffer. So might as well pass it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
There are currently compatibility issues between FreeRDP's implementation
of the RemoteFX codec and Microsoft's implementation.
Perhaps this will be fixed in the future and this option can go away,
but for now it's necessary to have a way to disable the codec if the
windows client is going to be connecting to a weston server.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
The repaint_data is entirely backend specific. Moreover, it is only used by the
drm backend, while other backends ignore the repaint data.
There will always be only one repaint active, thus, there is no need to pass the
repaint data from the outside.
The repaint_data breaks with the multi-backend series, which calls repaint begin
for all backends to get the repaint_data. The repaint_data of the last backend
will then be passed to all other backend. At the moment, this works, because the
drm backend is the only backend that implements the begin_repaint call.
Another option would be to track the repaint data per backend in the compositor,
but actually, it the backend needs to track state across the calls, it's its own
responsibility.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Fbdev backend was deprecated in the Weston 10.0.0 release with
6338dbd581. Before that, I suggested
already in 2019 to remove it, but it was too soon then. Now it seems the
final voices asking for fbdev to be kept have been satisfied, see the
linked issue.
Fbdev-backend uses a kernel graphics UAPI (fbdev) which is sub-par for a
Wayland compositor: you cannot do GPU accelerated graphics in any
reasonable way, no hotplug support, multi-output support is tedious, and
so on. Most importantly, Linux has deprecated fbdev a long time ago due
to the UAPI fitting modern systems and use cases very poorly, but cannot
get rid of it if any users remain. Let's do here what we can to reduce
fbdev usage.
I am doing color management related additions to libweston which require
adding checks to every backend. One backend less is less churn to write
and review.
Libweston major version has already been bumped to 11, so the next
release will be Weston 11, without fbdev. enum weston_compositor_backend
entries change their numerical values.
Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/581
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The built-in backend of libseat requires users to enable a logging
level in order for libseat to start writing out log messages. For that
to happen we split out the info and error log level messages into the
compositor's log scope, while debug level messages go into a dedicated
scope.
With that, this patch brings in a new scope, called libseat-debug, which
users need to explicity create a subscription for it as to retrieve/have
access to debug message coming out of libseat. Note that by default we
have a subscription for the log-scope so any errors/info from libseat
would be displayed to the user.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This doesn't work with any of the launchers we've kept. Remove the option
and all the bits that handle it.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Zoom is a neat trick, but in its current form it's very hard to test
and maintain.
It also causes output damage to scale outside of the output's boundaries,
which leads to an extra clipping step that's only necessary when zoom
is enabled.
Remove it to simplify desktop-shell and compositor.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
There is no weston_surface_set_transform_parent(), it is called
weston_view_set_transform_parent() now since
a7af70436b .
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
When we first create a drm_fb from a weston_buffer, cache it and keep it
alive as long as the buffer lives. This allows us to reuse the gbm_bo
and kernel-side DRM framebuffer, rather than constantly creating and
destroying them at every repaint. The overhead of doing so (e.g. MMU
updates) can be significant on some platforms.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This adds the initial dma-buf feedback implementation, following the
changes in the dma-buf protocol extension.
The initial dma-buf feedback implementation gives support to send
default feedback and per-surface feedback. For now the per-surface
feedback support is very basic and is still not implemented in the
DRM-backend, what basically means that KMS plane's formats/modifiers are
not being exposed to clients. In the next commits of this series we add
the DRM-backend implementation.
This patch is based on previous work of Scott Anderson (@ascent).
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Add API to set an output's color profile. This new function can also be
called while the output is enabled. This allows changing the output
color profile even at runtime if desired.
color-noop has no way of creating weston_color_profile objects, so it
just asserts that no color profile is set.
color-lcms does not yet implement taking the output color profile into
account, so for now it just fails everything if a profile is set.
weston_surface_color_transform_fini() was previously used only prior to
freeing the struct, but now it is used also to just clear the struct,
hence it needs to reset the fields.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This function will be useful for Weston to load output ICC profiles from
weston.ini.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Roughly speaking, a color profile describes the color space of content
or an output. Under the hood, the description includes one or more ways
to map colors between the profile space and some standard profile
connecting space (PCS).
This object is not called a color space. A color space has a unique
definition, while a color profile may contain multiple different
mappings depending on render intent. Some of these mappings may be
subjective, with an artistic touch.
When a source color profile and a destination color profile are combined
under a specific render intent, they produce a color transformation.
Color transformations are already preresented by weston_color_transform.
This patch adds the basic API for color profile objects. Everything
worthwhile of these objects is implemented in the color managers:
color-noop never creates these, and in color-lcms they are basically a
container for cmsHPROFILE, the Little CMS object for color profiles.
Color profile objects will not be interpreted outside of the color
managers, unlike color transformations.
For a start, the color manager API has one function to create color
profiles: from ICC profile data. More creation functions for other
sources will be added later.
The API has errmsg return parameter for error messages. These are not
simply weston_log()'d, because CM&HDR protocol will allow clients to
trigger errors and the protocol handles that gracefully. Therefore
instead of flooding the compositor logs, the error messages will
probably need to be relayed back to clients.
Color-lcms is expected to create a cmsHPROFILE for all kinds of color
profiles, not just for those created from ICC profile data. Hence,
color-lcms will fingerprint color profiles by the MD5 hash which Little
CMS computes for us. The fingerprint is used for de-duplication: instead
of creating copies, reference existing color profiles.
This code is very much based on Sebastian Wick's earlier work on Weston
color management, but structured and named differently.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
If two or more clients were running and the one that was focused when
weston itself lost keyboard focus was killed, weston would crash.
This is because commit 85d55540cb changed the way we handle saved keyboard
focus when we lose focus, and did so in such a way that the saved keyboard
focus listener could be removed from the surface destroy signal list
during the emit of the surface destroy signal. This corrupted the list
and led to a NULL pointer dereference.
Fix this by using a boolean flag to determine whether we should obey the
saved keyboard focus. We can set this safely in cases where
removing the listener would cause a crash.
Fixes#138
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This creates the color-lcms plugin that in the future will be using
Little CMS as the color matching module, processing ICC profiles, and
producing HDR tone mappings.
Right now, this new plugin is functionally equivalent to the no-op color
manager, except it already links to lcms2 and checks that the renderer
supports color operations.
Color-lcms is a libweston plugin that is loaded with explicit
weston_compositor API. This does not currently allow loading alternative
color manager plugins. External color manager plugins might be
considered in the future when the libweston APIs around color management
stabilize.
This libweston plugin uses the same build option as the old cms-static
Weston plugins, as they both need lcms2. The minimum version for lcms2
was chosen by what Debian Buster provides today and for no other reason.
This plugin intends to support the Wayland CM&HDR protocol extension and
hence sets supports_client_protocol to true. This will expose the
protocol extension to clients when it gets implemented.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is needed when the compositor produces any content internally:
- the lines in triangle fan debug
- the censoring color fill (unmet HDCP requirements)
Solid color surfaces do not need this special-casing because
weston_surface is supposed to carry color space information, which will
get used in gl_shader_config_init_for_view().
This makes sure the internally produced graphics fit in, e.g on a
monitor in HDR mode.
For now, just ensure there is an identity transformation. Actual
implementations in GL-renderer will follow later.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is needed when drawing anything internal directly to an output,
like the borders/decorations in a nested compositor setup. This makes
the assumption that the internal stuff starts in sRGB, which should be
safe. As borders are never blended with other content, this should also
be sufficient.
This patch is a reminder that that path exists, rather than a real
implementation. To be implemented when someone needs it.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is the blending space to monitor space color transform. It needs to
be implemented in the renderers, unless a backend sets
from_blend_to_output_by_backend = true, in which case the backend does
it and the renderer does not.
The intention is that from_blend_to_output_by_backend can be toggled
frame by frame to allow backends to react to dynamic change of output
color profile.
For now, renderers just assert that they don't need to do anything for
output color transform.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
See: https://gitlab.freedesktop.org/wayland/weston/-/issues/467#note_814985
This starts building the framework required for implementing color
management.
The main new interface is struct weston_color_manager. This commit also
adds a no-op color manager implementation, which is used if no other
color manager is loaded. This no-op color manager simply provides
identity color transforms for everything, so that Weston keeps running
exactly like before.
weston_color_manager interface is incomplete and will be extended later.
Colorspace objects are not introduced in this commit. However, when
client content colorspace and output colorspace definitions are
combined, they will produce color transformations from client content to
output blending space and from output blending space to output space.
This commit introduces a placeholder struct for color transforms,
weston_color_transform. Objects of this type are expected to be heavy to
create and store, which is why they are designed to be shared as much as
possible, ideally making their instances unique. As color transform
description is intended to be generic in libweston core, renderers and
backends are expected to derive their own state for each transform
object as necessary. Creating and storing the derived state maybe be
expensive as well, more the reason to re-use these objects as much as
possible. E.g. GL-renderer might upload a 3D LUT into a texture and keep
the texture around. DRM-backend might create a KMS blob for a LUT and
keep that around.
As a color transform depends on both the surface and the output, a
transform object may need to be created for each unique pair of them.
Therefore color transforms are referenced from weston_paint_node. As
paint nodes exist for not just surface+output but surface+view+output
triplets, the code ensures that all paint nodes (having different view)
for the same surface+output have the same color transform state.
As a special case, if weston_color_transform is NULL, it means identity
transform. This short-circuits some checks and memory allocations, but
it does mean we use a separate member on weston_paint_node to know if
the color transform has been initialized or not.
Color transformations are pre-created at the weston_output
paint_node_z_order_list creation step. Currently the z order lists
contain all views globally, which means we populate color transforms we
may never need, e.g. a view is never shown on a particular output.
This problem should get fixed naturally when z order lists are
constructed "pruned" in the future: to contain only those paint nodes
that actually contribute to the output's image.
As nothing actually supports color transforms yet, both renderers and
the DRM-backend assert that they only get identity transforms. This
check has the side-effect that all surface-output pairs actually get a
weston_surface_color_transform_ref even though it points to NULL
weston_color_transform.
This design is inspired by Sebastian Wick's Weston color management
work.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Layers did not have a fini sequence before, which means the compositor
layer list might have stale pointers temporarily when shutting down. A
bigger problem might be having views linger after the destruction of the
layer.
These problems were not observed yet, but if they exist, this patch
should help to find them and then fix them.
The check in weston_compositor_shutdown() is not an assert yet, because
it will trigger until all components call weston_layer_fini() correctly.
Some components do not even have a tear-down function to call it from at
all, like fullscreen-shell.
The same with the check in weston_layer_fini().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This patch creates a per-output paint node list in the same z-order as
the global view_list in weston_compositor.
The next step is to switch output repaints and backends to use the
z-order list instead of view_list.
Having a per-output paint node list for repaints allows including only
those paint nodes that actually contribute to the output image, so that
completely occluded and out-of-screen views can be ignored in libweston
core already.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This new object is created for every surface-view-output triplet. As
there is always exactly one surface for a view and it does not change
during a view's lifetime, this is really for a view-output pair or a
surface-output pair.
The object is created on-demand as a part of preparing for an output
repaint, so it applies only to surfaces that are going through repaint.
A prerequisite for that is that the surface is mapped, which means it
has a mapped view.
When any one of surface or view gets destroyed or output gets disabled,
all related paint nodes are destroyed.
In future, paint node will be useful for caching surface-output or
view-output pair dependent data:
- damage regions for overlapping outputs
- color transformations
- backend-specific bookkeeping (e.g. DRM KMS plane assigments)
- per-output repaint lists
- surface geometry transformed into output space
Suggested by Daniel Stone in
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/582#note_899406
PS. The call in weston_view_destroy() to
weston_compositor_build_view_list() might be so that if the view has
sub-surfaces, rebuilding the view list removes those those too and
automagically deletes their views.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
In commit "libweston: add struct weston_drm_format" struct
weston_drm_format and its helper functions were added to libweston.
The functions query_dmabuf_formats and query_dmabuf_modifiers are very
specific to GL-renderer and its internals. So instead of exposing them
in libweston, query and store DRM formats and modifiers internally in
GL-renderer. Also, add a vfunction to struct weston_renderer in order
to retrieve the formats.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This allows tests to skip when required capabilities are not present.
The output damage test for the shadow buffer case needs this.
required_capabilities is added to struct weston_testsuite_quirks which
is libweston public API just because there is no better place currently.
This is a little weird because the code to check it is in compositor,
not libweston.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This adds a heuristic for freeing shader programs that have not been
needed for a while. The intention is to stop Weston accumulating shader
programs indefinitely, especially in the future when color management
will explode the number of possible different shader programs.
Shader programs that have not been used in the past minute are freed,
except always keep the ten most recently used shader programs anyway.
The former rule is to ensure we keep shader programs that are actively
used regardless of how many. The latter rule is to prevent freeing too
many shader programs after Weston has been idle for a long time and then
repaints just a small area. Many of the shader programs could still be
relevant even though not needed in the first repaint after idle.
The numbers ten and one minute in the above are arbitrary and not based
on anything.
These heuristics are simpler to implement than e.g. views taking
references on shader programs. Expiry by time allows shader programs to
survive a while even after their last user is gone, with the hope of
being re-used soon. Tracking actual use instead of references also
adapts to what is actually visible rather than what merely exists.
Keeping the shader list in most recently used order might also make
gl_renderer_get_program() more efficient on average.
last_repaint_start time is used for shader timestamp to avoid calling
clock_gettime() more often. Adding that variable is an ABI break, but
libweston major has already been bumped to 10 since last release.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Extend the existing output-damage test to test
blit_shadow_to_output() specifically. This function had problems
originally, so make sure they can't reappear.
The added quirk is explained in the test.
An additional check of the quirk in gl_renderer_output_create() ensures
that the shadow framebuffer is really used. The test could false-pass if
the shadow is not used.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This adds the libweston capability bit for "color operations" which
refers to a renderer's support for operations needed for color
management. GL-renderer will grow the support while Pixman-renderer will
not, which is why the cap is needed.
To make an example use of the cap, this also adds new API:
weston_output_set_renderer_shadow_buffer(). This is a temporary API to
enable future experimental features. The first such feature will be the
renderer internal shadow buffer, the boolean variable for it taken from
Harish Krupo's "weston.ini: introduce use-shadow-fbo in output config".
Obviously this patch does not implement the renderer shadow buffer. No
renderer sets WESTON_CAP_COLOR_OPS yet so trying to enable it will fail.
The documentation here is deliberately vague, because the bits needed
for color management will come in trickling for a long time until we can
call it color management in any sense. Until then, the temporary API
shall remain, perhaps poorly named.
Cc: Harish Krupo <harishkrupo@gmail.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This test ensures that client submitted damage goes to the screen
correctly, regardless of output scale or transform.
The added quirk is explained in the test that uses it.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Without this patch, the DRM-backend would rewrite the 'require-input',
core section option given by the user.
This removes 'continue_without_input' DRM-backend option and takes into
consideration the cmd line option only if that was passed (Pekka Paalanen).
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Until now we had the test quirks initialization in wet_main(),
just after calling weston_compositor_create(). But there are
some cases that require the quirks during struct weston_compositor
creation time.
Move test quirks initialization to weston_compositor_create()
in order to cover more use cases for the test quirks mechanism.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Until now we had struct wet_testsuite_data as an opaque
struct that should be defined by the testsuite of libweston
users. Instead, keep the data as a void * and document that
users are responsible for defining the data type.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
There are some specific cases in which we need Weston to
behave differently when running in the test suite. This
adds a new API to allow the tests to select these behaviors.
For instance, in the DRM backend we plan to add a writeback
connector screenshooter. In case it fails for some
reason, it should fallback to the renderer screenshooter
that all other backends use. But if we add a test to
ensure the correctness of the writeback screenshooter,
we don't want it to fallback to the renderer one, we
want it to fail. With this new API we can choose to
disable the fallback behavior specifically for this test.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
directory
Weston is also a user of the plug-ins, so make use of it. With this
change we unconditionally install the plug-in headers even though
libweston might not be built with support for them.
Suggested-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
In the test suite we may want to run a DRM-backend test on a
non-default seat, which may not have a input device associated.
Weston's default behavior is to not open if input devices are
not found, as it may cause troubles. For instance, Weston can
open but if no input device is set than the user can not
interact or leave it.
Add flag --continue-without-input to DRM-backend so we can run
these types of tests with no input. Notice that this won't force
the compositor to skip opening a input device if it finds it on
the non-default seat.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Like physical size, subpixel arrangement, etc, transform advises of a
physical transform of a head, if present.
This commit adds the transform member and setter to weston_head, however
it is currently unused.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
[daniels: Extracted from one of Lucas's patches.]
Signed-off-by: Daniel Stone <daniels@collabora.com>
Log subscriber API is not type-safe. File and flight recorder
subscribers are created with functions that return
weston_log_subscriber objects. But there's a problem: to destroy
these objects you have to call the right function for each type
of subscriber, and a user calling the wrong destroy function
wouldn't get a warning.
Merge functions that destroy different types of subscribers, making
the log subscriber API type-safe.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
The only reason why we have both weston_compositor_tear_down() and
weston_compositor_destroy() is that the only we had to destroy
the log context was keeping weston_compositor alive and calling
weston_log_ctx_compositor_destroy().
After commit "weston-log: replace weston_log_ctx_compositor_destroy()
by weston_log_ctx_destroy()", it's not necessary to keep a zombie
weston_compositor just to be able to call
weston_log_ctx_compositor_destroy().
Fold weston_compositor_tear_down() into weston_compositor_destroy(),
as this split is useless now.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
The function weston_log_ctx_compositor_destroy(), which destroys struct
weston_log_context, takes weston_compositor as argument. We may have a
weston_log_context unlinked from a weston_compositor and currently there
is no way to destroy it.
Add function weston_log_ctx_destroy(), what makes the destruction of
weston_log_context independent of weston_compositor.
With this change, one could destroy a weston_compositor and keep the
related weston_log_context (since now weston_log_context can be destroyed
without the need of a weston_compositor). But if weston_compositor gets
destroyed it's also necessary to destroy weston_log_context::global,
as the debug protocol depends on the compositor. So a listener has been
added to the destroy signal of weston_compositor.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Since weston_log_ctx_compositor_create() does not have any relation
with weston_compositor, rename it to weston_log_ctx_create().
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
If we use the function weston_log_context_add_log_scope()
in non-core code, it's necessary to access
weston_compositor::weston_log_ctx.
This is not ideal, since the goal is to make core structs
(weston_compositor, weston_surface, weston_output, etc)
opaque.
Add function weston_compositor_add_log_scope(), so non-core
users are able to pass weston_compositor as argument instead
of weston_compositor::weston_log_ctx.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
There's a function named weston_compositor_log_scope_destroy()
but it doesn't take a struct weston_compositor argument.
Rename it to weston_log_scope_destroy(), as the argument is a
struct weston_log_scope.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
There's a function named weston_compositor_add_log_scope()
but it doesn't take a struct weston_compositor argument.
Rename it to weston_log_ctx_add_log_scope(), as
the log_scope is being added to a log_context.
Also, bump libweston_major to 9.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
In the function weston_log_subscription_printf() we have
a struct weston_log_subscription parameter that in the .c file
is named sub. In the .h, the same parameter is named scope.
This is confusing, since its type is not struct weston_log_scope,
but struct weston_log_subscription.
Rename the parameter in the .h to sub.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
In the function weston_compositor_add_log_scope() we have
a struct weston_log_context parameter that in the .c file
is named log_ctx. In the .h, the same parameter is named
compositor. This is confusing, since its type is not
struct weston_compositor, but struct weston_log_context.
Rename the parameter in the .h to log_ctx.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
When we were designing the libweston output API, I wrote a design document
as a Phabricator wiki page. Phabricator is no longer accessible so that
information needs to be migrated to a new place. Here I am converting most of
it into libweston Sphinx documentation, particularly pulling in the sequence
diagrams I drew. This should help people understand how libweston output
configuration works.
The diagrams are committed as both MSC source files and rendered PNG files. I
did not bother tinkering with the build to run mscgen automatically and then
with the CI images to install the tool.
The Sphinx configuration need numref explicitly enabled so that figures are
automatically numbered and can be referenced by their number rather than their
whole caption text(!).
The document structure is changed a little better flowing with Output
Management being the overview page and the Heads and Outputs being the API
pages.
First I wrote the struct weston_output and weston_head descriptions in Doxygen
comments in libweston.h, but then in the API page that text would have been
buried somewhere towards the end of the page. So I put that text in ReST
instead where it comes as first on the pages as it should. The doc for the
structs only contain a link to the top of the page. Yes, the comment style in
libweston.h is a little broken. If I left the asterisk there it would show up
as a bullet point in Sphinx. OTOH putting everything from \rst in a single line
did not produce anything.
Because Sphinx cannot look in two places, the images need to be copied into the
build dir too.
mscgen: http://www.mcternan.me.uk/mscgen/
Fixes: https://gitlab.freedesktop.org/wayland/weston/issues/25
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The member previous_damage from struct weston_output is no longer necessary.
First, stop calling init, fini and copying output_damage to it. Then remove
it from struct weston_output.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
