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>
Forward the HDR Static Metadata Type 1 to the video sink. This makes the
sink aware of our video content parameters and may be able to produce a
better picture. This type of metadata is used only with the ST 2084 HDR
mode a.k.a PQ.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This creates a new file for KMS related color code, to avoid making
drm.c even longer.
The moved code was just added in 5151f9fe9e
so the new file copyrights are written based on that.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
'color_characteristics_config_error' test ensures that all code paths in
parse_color_characteristics() and wet_output_set_color_characteristics()
get exercised. The return value and logged error messages are checked.
Other cases test the weston_hdr_metadata_type1 validation.
These are for the sake of test coverage, but also an example of how to
test a function from main.c, and how to capture messages from
weston_log().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Check that weston.ini settings to eotf-mode and basic color
characteristics are correctly parsed.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is the beginnings of creating composited content HDR metadata for
the ST2084 HDR mode. The immediate goal is to allow essentially setting
the HDR metadata from weston.ini, so that it can be experimented with.
Setting an output ICC profile will stop weston.ini metadata from taking
effect, but using an ICC profile in HDR mode is an open question anyway.
maxDML, maxCLL, and minDML are set based on the assumption that we want
to make use of the full sink/monitor dynamic range.
This also adds several TODOs about how we should handle output profiles,
basic output color characteristics, and HDR metadata. Implementing these
properly will take more thought and effort.
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 an option to program basic display color characteristics from
weston.ini. In the future there will be a way to set this information
from EDID, but because EDID is unreliable that will probably not be the
default. An ICC profile will likely override most or all of this. The
main reason to add this option is to be able to characterise HDR
monitors.
An 'output' section can have a key 'color_characteristics' (string)
set to a name. The name refers to any 'color_characteristics' section
with 'name' set to the same string.
The 'name' key of a 'color_characteristics' section cannot contain a
colon ':'. Names with colon in 'output' section key
'color_characteristics' value are reserved for future use, e.g. to
indicate that the metadata is to be taken from EDID instead of a
weston.ini section.
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>
Instead of a meson option or hidden define, just run these checks always.
It is not Weston's style to add build options for specific asserts, and
currently weston's codebase is expected to always run with asserts
enabled.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
It is used in Mesa. Lets switch to it as well in order to provide
good examples and encourage proper API usage.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Compositors may choose to send multiple scanout or non-scanout
tranches. So instead of assuming that the first respective tranche
contains the format/modifier we're looking for, check all tranches.
While on it, make sure that in case a compositor sends scanout
tranches on the initial feedback, `pick_format_from_scanout_tranche()`
does not unintentionally pick `INITIAL_BUFFER_FORMAT`.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
It doesn't and can't build, because it depends on cairo-gl. We already
have simple-egl which shows how to use EGL/GLESv2 on Wayland.
Signed-off-by: Daniel Stone <daniels@collabora.com>
It's three planes, not two.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: 8b167a1703 ("gl-renderer: Store EGL buffer state in weston_buffer")
There's just no good reason to do this.
The query entrypoints already tell us if we need to use
GL_TEXTURE_EXTERNAL_OES for a particular format/modifier. We also have
RGB -> YUV fallbacks which should be able to work well with TEXTURE_2D.
TEXTURE_EXTERNAL pessimises quite hard, forcing GPU-side reloads as well
as bad filtering. Allowing multi-planar formats to use TEXTURE_2D should
thus result in performance and quality improvements.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Now that we can pull everything we need from pixel-formats, go one step
further and reuse the same YUV format descriptors we use to emulate
dmabuf/EGLImage imports for SHM.
This eliminates all special-case YUV/SHM handling.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Add a new hide_from_clients flag which, if set, specifies that the
format is only for internal information and processing, and should not
be advertised for clients.
This will be used for formats like R8 and GR88, which are not useful for
client buffers, but are used internally to implement YUV -> RGB
conversion.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We support this as an explicit YUV fallback path in gl-renderer's dmabuf
EGLImage import path, so might as well support it in the SHM path, given
it's just YUV420 with no subsampling.
Signed-off-by: Daniel Stone <daniels@collabora.com>
If we're doing partial uploads from SHM buffers, we need to use the
vertical subsampling factor rather than the horizontal for secondary
planes.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We already had these with effective width and height, but they're useful
externally as well. Pull them out to a helper.
Signed-off-by: Daniel Stone <daniels@collabora.com>
'depth' isn't actually used to determine the bit depth of meaningful
components generally, but specifically to determine whether we can use
the legacy drmModeAddFB (pre-AddFB2) with those formats.
Rename the member to make it more clear what it's used for.
Signed-off-by: Daniel Stone <daniels@collabora.com>
pixel-formats already stores the gl_format, at least for single-planar
formats; use that instead of storing our own copies.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Instead of checking for each format whether we need compatibility
workarounds for GL implementations not supporting ES3.x or when
GL_EXT_texture_rg isn't present, have each format declare the ideal case
and fix it up later.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Rather than checking all the pixel-format components which are currently
duplicated inside gl-renderer, just check for equality of the pixel
format itself, which will become useful as we remove some of the
duplicate content.
This means that the texture storage will now be reallocated when clients
switch between pixel formats which could've had compatible GL storage
(e.g. XRGB <-> ARGB) on the same surface. However this does not seem
like a case worth optimising, and simplifies the code somewhat.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We've got a nice shiny ARRAY_COPY macro, so use it rather than memcpy or
hand-unrolled assignments.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Allow clipboard pasting in and out of an RDP session.
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>
RDP exposes certain features (audio, clipboard, RAIL) through a facility
called "virtual channels". Set up the communications framework for using
these.
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>
FreeRDP has some features that start new threads and run
callback functions in them.
We need a way to punt work from these threads back to the
compositor thread.
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>
Log EGL features similar to how GL ES features are logged: listing just
the ones weston tests for.
This replaces some log messages from gl-renderer.c that become
redundant or belong with EGL better.
has_native_fence_sync and has_wait_sync are not logged, because missing
them already logs warnings.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Feels like this might be nice to log.
The failure case is not fatal, so say it's a warning only.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is a human readable replacement for printing out the list of all
available GL extensions that doesn't happen anymore by default.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Print all EGL and OpenGL extension lists into a new log scope
"gl-renderer" instead of the usual log.
These lists cluttered the log while they were very rarely actually
useful. Sometimes they might be interesting, so make them still
available through the new log scope.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Plumb struct gl_renderer all the way through to
gl_renderer_log_extensions(). In the future, the extension lists will be
printed into a debug scope specifically, and it will get the debug scope
from gr.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This fixes the following leaks for
weston_curtain/weston_buffer_create_solid_rgba when shutting down the
compositor:
#0 0x7f9170372987 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7f915bfeb8b7 in zalloc ../include/libweston/zalloc.h:38
#2 0x7f915bfec71d in weston_curtain_create ../shell-utils/shell-utils.c:150
#3 0x7f915bfd9e51 in shell_ensure_fullscreen_black_view ../desktop-shell/shell.c:2082
#4 0x7f915bfda2a9 in shell_configure_fullscreen ../desktop-shell/shell.c:2118
#5 0x7f915bfdc72d in desktop_surface_committed ../desktop-shell/shell.c:2538
#6 0x7f915bfa3ef5 in weston_desktop_api_committed ../libweston-desktop/libweston-desktop.c:159
#7 0x7f915bfae778 in weston_desktop_xdg_toplevel_committed ../libweston-desktop/xdg-shell.c:746
#8 0x7f915bfb0d45 in weston_desktop_xdg_surface_committed ../libweston-desktop/xdg-shell.c:1374
#9 0x7f915bfa7382 in weston_desktop_surface_surface_committed ../libweston-desktop/surface.c:174
#10 0x7f916fe628a6 in wl_signal_emit /home/mvlad/install-amd64/include/wayland-server-core.h:481
#11 0x7f916fe7c0e2 in weston_surface_commit_state ../libweston/compositor.c:4062
#12 0x7f916fe7c161 in weston_surface_commit ../libweston/compositor.c:4068
#13 0x7f916fe7c6ef in surface_commit ../libweston/compositor.c:4146
#14 0x7f916fc847e9 (/usr/lib/x86_64-linux-gnu/libffi.so.8+0x77e9)
#0 0x7f9170372987 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7f916fe62aa3 in zalloc ../include/libweston/zalloc.h:38
#2 0x7f916fe7398d in weston_buffer_create_solid_rgba ../libweston/compositor.c:2603
#3 0x7f915bfec879 in weston_curtain_create ../shell-utils/shell-utils.c:162
#4 0x7f915bfd9e51 in shell_ensure_fullscreen_black_view ../desktop-shell/shell.c:2082
#5 0x7f915bfda2a9 in shell_configure_fullscreen ../desktop-shell/shell.c:2118
#6 0x7f915bfdc72d in desktop_surface_committed ../desktop-shell/shell.c:2538
#7 0x7f915bfa3ef5 in weston_desktop_api_committed ../libweston-desktop/libweston-desktop.c:159
#8 0x7f915bfae778 in weston_desktop_xdg_toplevel_committed ../libweston-desktop/xdg-shell.c:746
#9 0x7f915bfb0d45 in weston_desktop_xdg_surface_committed ../libweston-desktop/xdg-shell.c:1374
#10 0x7f915bfa7382 in weston_desktop_surface_surface_committed ../libweston-desktop/surface.c:174
#11 0x7f916fe628a6 in wl_signal_emit /home/mvlad/install-amd64/include/wayland-server-core.h:481
#12 0x7f916fe7c0e2 in weston_surface_commit_state ../libweston/compositor.c:4062
#13 0x7f916fe7c161 in weston_surface_commit ../libweston/compositor.c:4068
#14 0x7f916fe7c6ef in surface_commit ../libweston/compositor.c:4146
#15 0x7f916fc847e9 (/usr/lib/x86_64-linux-gnu/libffi.so.8+0x77e9)
We do not migrate the weston_curtain destruction from
desktop_surface_removed() to desktop_shell_destroy_surface() because
we'd want have the curtain removed before the animation starts.
If we were to move the black view destruction, *and* only handle it from
desktop_shell_destroy_surface() the animation runs but the black curtain
will be removed right at the end, effectively diminishing the effect of
the animations.
To this end, we keep both of the two worlds, if the client terminates on
its own, we keep the same animation effect, but if the compositor is
shutting down we destroy it immediately.
We remove wl_list_for_each_safe() and instead loop each time to avoid
using a stale pointer iterator which could cause a UAF as the shsurf
would be free'ed.
Suggested-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Now that the gl_buffer_state owns everything related to buffers, move
the textures from there rather than living on the surface, to join the
EGLImage and/or SHM params.
Signed-off-by: Daniel Stone <daniels@collabora.com>
