Perhaps this would make things a bit more obvious to newcomers not
being familiar with historical 2D bitmap hardware sprite.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This disables all of the hardware planes not just overlay (primary and
underlays as well). Change also the debug message.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
The intention is that you should be able to replace these with the
pipewire-backend that you can load together with the DRM-backend. The
functionality should be equivalent, but the libweston software
architecture becomes more maintainable for upstream. Also the
pipewire-backend is not tied to the DRM-backend, and can work with any
other backend and even alone.
Once the remoting and pipewire plugins are gone, we can remove the
virtual output API from DRM-backend.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This was the original video recorder completely in software and with a
custom file format. It is no longer useful to keep. It used the old way
of getting screenshots: hooking to weston_output::frame_signal and
calling weston_renderer::read_pixels(). This old way stalled Weston
until the GPU work was complete, and supported only wl_shm buffers.
Nowadays video recording should be arranged with the pipewire-backend
which supports dmabuf delivery.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Unused.
This was using the old way of getting screenshots: hooking to
weston_output::frame_signal and calling weston_renderer::read_pixels().
This old way stalled Weston until the GPU work was complete, and
supported only wl_shm buffers.
At this time there is no libweston API for frontends/plugins to ask for
a screenshot, but there is a protocol interface in
weston-output-capture.xml.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
No functional change, just move the comments in the else branch.
Added with 5429302e, ("backend-drm: add KMS plane's formats to
per-surface dma-buf feedback").
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Meson's 'coverage-html' target defaults to using the Perl script LCOV.
LCOV has problems with newer GCCs like 14 in Debian Trixie, leading to
many consistency errors about function end lines. Gcovr OTOH runs just
fine.
Create a new target
$ meson compile gcovr-report
that creates a coverage report in HTML and Cobertura using gcovr.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
I was doing
$ mseon setup --wipe
$ meson test
and hit
../../git/weston/tests/constraints-test.c:31:10:
fatal error: pointer-constraints-unstable-v1-client-protocol.h:
No such file or directory
31 | #include "pointer-constraints-unstable-v1-client-protocol.h"
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
In function ‘encode_PAM_comment_line’,
inlined from ‘write_PAM_image_rgba’ at ../../git/weston/tests/surface-screenshot-test.c:85:9,
inlined from ‘trigger_binding’ at ../../git/weston/tests/surface-screenshot-test.c:202:8:
../../git/weston/tests/surface-screenshot-test.c:44:22: error: ‘desc’ may be used uninitialized [-Werror=maybe-uninitialized]
44 | size_t len = strlen(comment);
Fixes: d40af215a3
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Since the commit "color-lcms: extract HDR static metadata from profile"
this was all dead code.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Extract the HDR static metadata type 1 from the output color profile
directly, instead of relying on a separate weston.ini section to provide
the metadata separately.
Weston should tell the monitor what target color volume it is rendering
for. I don't see a reason to be able to control the metadata separately,
and it would add complexity.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Now that ICC<->parametric image description interoperability is
implemented, and the stock sRGB profile is parametric, we can change the
default to what it should be.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
TF_SRGB will be deprecated, best to never advertise it. The test can
simply use gamma22 instead.
TF_EXT_LINEAR has an implementation and should be usable nowadays.
TF_ST2084_PQ, GAMMA22 and GAMMA28 likewise.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Weston does not support the saturation rendering intent for parametric
image descriptions yet. Not really, Weston would just do the same as
media-relative with BPC does.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This avoids ICC paths when no ICC profiles are explicitly used.
We can simplify the profile information sending and use the generic path
for the stock profile as well, no longer hard-coding the stock profile
in two places.
Since the stock profile creation cannot fail, we can streamline
cmlcms_init() a little, too.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The icc<->parametric color transformation code uses "optical ICC
profiles" as part of the ICC pipeline. These profiles use a linear TRC
to encode the black point. When such TRC survives all optimizations, it
will cause the 3D LUT fallback path to be taken.
Detect such curve sets on the ICC pipeline optimizer, and convert them
to matrix stages. The matrix stages will then be optimized as usual,
often eliminating the stage completely.
The results can be seen in color-icc-output test after the stock sRGB
profile has been changed into a parametric one, causing all cases in the
test to hit the parametric-to-icc path. Some tests fail when they
suddenly start using the 3D LUT path which causes the errors to rise.
This patch fixes those (future) cases, and the errors remain the same as
before changing the stock profile.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
I don't have a specific use case in my mind for this, but it is
something we can easily handle.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
I need the new function for another purpose later, and this makes
get_parametric_curveset_params() easier to read.
Pure refactoring: no change in behavior.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Implementation of sending the protocol info events for an arbitrary
parametric image description.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The power-law TF uses a different protocol event than others. Adding
support for it requires passing in the parameters.
Now we have a single send function that handles all protocol TFs, not
just those without parameters.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Pure refactoring to clean up cmlcms_send_image_desc_info() ahead of
implementing generic parametric information sending.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Since glibc version 2.43, bsearch may return const void * instead of
void * when the input array is const:
"For ISO C23, the functions bsearch, memchr, strchr, strpbrk, strrchr,
strstr, wcschr, wcspbrk, wcsrchr, wcsstr and wmemchr that return
pointers into their input arrays now have definitions as macros that
return a pointer to a const-qualified type when the input argument is a
pointer to a const-qualified type."
So change variable that receives the return value from bsearch to const,
as the input array has the const qualifier. This fixes a "discards const
qualifier from pointer" error.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Before, these pieces of code were allocating, formatting and freeing the
bit flags string regardless of whether debug logging was used or not.
Now, the bit flags string is formatted only when debug logging is
active, and it does not involve malloc+free.
This should improve performance a bit.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The only difference is a small one in the debug print, otherwise this is
completely identical.
Makes drm_pending_state_apply_atomic() slightly more maintainable.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This should cut the cost of debug_scene_view_print_buffer() in half on
ARM A55 CPU. Debug printing is quite expensive on such platform.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Two lines open-coded in two places was not much a problem, but I'm going
to add a new member to weston_buffer that needs freeing, and I want to
do it in just one place.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Use fputs() as much as possible. My theory is that since fprintf() needs
to scan through the format string to find any formatting codes, it must
be less efficient than fputs() that does not scan.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is useful for cases where we already have an open stream which we
can pass straight in and use it when printing node information.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Being able to print the scene-graph straight into a FILE removes one
temporary memory allocation that used to be mandatory. That memory
allocation is now gone from the DRM-backend debug log. It has moved into
the scene-graph log scope. In the case of
weston_log_subscription_printf() it shouldn't matter, because it is only
used when new subscribers appear.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The old implementation malloc'd a temporary buffer to hold the formatted
string, flushed it out to subscribers, and freed the buffer. On every
single call.
Forwarding the formatted output to the input stream instead avoids the
malloc. It is flushed explicitly so that interleaving messages through
multiple scopes continues to work. Color-lcms module uses that.
Also fix reference to the non-existing function
weston_debug_stream_write().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Printing directly into an stdio stream and hooking up to the flush (the
write callback) avoids having to allocate+free a temporary buffer on
every printing call. The FILE uses a permanent buffer for storing the
text, and once it fills up or a newline is detected, it is flushed out.
It is fine to mix the new and the old APIs, since the old API flushes
the stream.
The buffer size of 3 kB is just a guess.
The man-page for fopencookie() recommends setting _FILE_OFFSET_BITS to
64. Even though this patch does not strictly need it (we don't implement
seek or take the address of fopencookie()), I think it's good to follow
anyway.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
When building without any of the x11 and wayland we still to have some
unused variables/functions.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Fix compilation errors when compiling with x11 or wayland backends
disabled or not available.
Fixes: 8f56d03d ("libweston: Vulkan renderer")
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
We may break out of the loop if wl_display_dispatch(client->wl_display)
fails and returns -1. So we need to assert that info->done is true after
the loop.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
We've just added support for grayscale output color effect. This adds
test cases for that.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This adds a new output color effect: grayscale. It takes RGB color as
input and computes a gray pixel color using the luminance formula for
linear sRGB:
Y = 0.2126 * R + 0.7152 * G + 0.0722 * B
Just like the other color effects we have, this only works for sRGB and
are not enabled when color-management is on.
Note: although the technique is designed to be applied in linear, it's
costly to convert to linear and then back to electrical. As doing the
conversion in electrical still gives a reasonable result, we do it this
way. When we add support for color effects with color-management on,
we'll apply the effect in linear.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This was logging the CVD correction effects, but not the inversion one.
This commit adds this.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
The explanation of what a color inversion is was not clear. With this
commit we improve that.
Color inversion computes the RGB complement (i.e. 1.0 - color) of the
input.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This function has a few leftovers. At first (downstream) it was
returning error, and callers would handle it. The effect would be a
black screen in case of failure.
Instead, when the MR was proposed we've decided to just log an error and
not set the effect, as it is easy to see that the effect is not applied.
It is better displaying the output without effects than a black screen.
We ended up with a function that always return success. So let's remove
the return value and simplify callers.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
When selecting a crtc for an output, prefer the first available crtc that
supports the most hardware planes.
This increases the chance that the compositor can make use of hardware planes
for compositing instead of falling back to rendering just because it selected a
crtc that only supports one plane.
I found this on i.MX6, which has 4 crtcs and 6 planes. crtc 0 and crtc 2 have
two planes, and crtc 1 and crtc 3 have one plane. The current selection
algorithm selects the last matching crtc, which is crtc 3 and prevents the use
of planes.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Now that we have per output plane lists, we can make the overlay/underlay
subtype be part of the plane handle, and make the has_underlay property
part of the output.
This fixes bugs on platforms where not all CRTCs have the same
minimum zpos, and underlays can be broken for all outputs because
one output doesn't have any.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
