In a future commit, we'll need weston_subsurface_parent_commit sooner,
so just move both of these prototypes earlier in the file.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We don't use it anymore, we just casually commit and expect that
applying clean state is harmless.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
It really doesn't matter if we do a little extra work here,
weston_subsurface_commit_from_cache() is harmless if called on clean state.
If this turns out to waste some cycles we can add some more dirty bits
later.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We called subsurface_parent_commit with a flag to indicate whether we're
committing from a synchronized parent or not - this was used for
determining if a subsurface was effectively synchronized.
Now that we know whether a subsurface is effectively synchronized, we
can drop the parameter.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This was used to check if a subsurface was effectively sync,
and we now have a bool to check for that instead.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Keep track of subsurface effective sync status when it changes instead of
figuring it out when we need to know it.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Create a common weston_surface_apply() for both subsurface and normal
surfaces to push state through, as this will let us remove a bunch of
common code in the future.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Continuing to make a split between "commit" and "apply" in preparation
for a future where the application happens later.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We'll eventually have a hard split between the commit and the application
of state, so rename this function to better indicate what it does.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Use the shared helper in order to avoid duplication. This will also
ensure that any format added to the test will also be usable by other
tests and clients.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Factor out client-buffer creation into a helper library in order to
avoid duplication. This notably allows clients and tests to easily reuse
the dmabuf and yuv logic.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Historically, weston-screenshooter attempts a capture on all
wl_outputs, and if any output fails to capture it exits immediately.
These days it's possible to set up the pipewire backend to mirror
a drm backend output. This leads to surprising behaviour if one
tries to screenshot while no pipewire client is in use. Since the
pipewire backend has no buffer to render into at this point, the
screenshot fails. The drm screenshot is then dropped on the floor
because one of the wl_outputs failed to capture.
Avoid this for now by just continuing in the case of such
"graceful failures". Though maybe in the future we should allow
picking a wl_output by name, or have a command line switch to
decide whether to stop after a failure or not.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
If there's no running connection, we can't capture, so just burn down any
waiting tasks so we don't assert later.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Listen to the capture destroy signal so we can prevent the async fd
source from causing a UAF.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
An output task may be destroyed by a client disconnect. This causes
problems for our drm backend's asynchronous capture task handler, which
currently has no way to notice this.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
No functional change.
This will help to keep the code more straightforward when
parametric<->ICC color transformations are added, and they need more
operations than just the cmap_3dlut for the 3D LUT.
Particularly, there will be a new flag telling if cmap_3dlut is
populated, and the flag is best set in init_icc_to_icc_chain() instead
of xform_realize_chain().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
When crafting an ICC to ICC color transformation, all the steps in
weston_color_transformation are at disposal. In the future also
parametric<->ICC color transformations will be crafted using the same
ICC chain machinery. However, there some steps must be reserved for
additional operations.
Add a bit mask that tells which color steps can be used by
xform_realize_icc_chain().
Unfortunately the mask is most conveniently stored in struct
cmlcms_color_transform. The LittleCMS context user data is the only good
way of passing our own bits into the factory code, but the user data
cannot be reset without destroying the context. It is probably not safe
to destroy the context as long as we have any LittleCMS objects alive
and created in that context. Hence, the user data must out-live the
LittleCMS context.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
I will be adding a MAPPING value, and it would look odd without any
prefix. This adds a bit of namespacing.
The definition is moved to the header, because I will be needing it in
struct cmlcms_color_transform.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Split init_icc_to_icc_chain() into two parts:
- init_icc_to_icc_chain() is specific for ICC to ICC transformation
- xform_realize_icc_chain() can process any chain of cmsHPROFILEs
xform_realize_icc_chain() will be used by ICC-to-parametric and
parametric-to-ICC transformations in following commits.
No changes to functionality. 'extra' local variable is lost as unused.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
I will be splitting this function, and xform_realize_chain() matches the
parts I'm going to split out of it, while the remainder will be specific
to icc-to-icc transformations.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
In this patch we allow offloading the post-blend color transformation
to KMS.
As KMS currently only supports to offload the transformation in a LUT,
this may result in precision issues. So this introduces the config
option "offload-blend-to-output", which is disabled by default.
This option requires "color-management" to be enabled, otherwise it is
ignored.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
We already get the core section a few lines above, and no other call
get_section() call are made in between.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This is a leftover from "color: do not use color steps for non-optimized
pipelines". If a xform don't have valid steps, it shouldn't have curves.
So this function should fail.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
At this point, the DRM/KMS API supports offloading post-blend color
xform only through LUT's. This is not ideal, and an API to improve that
should be proposed in the future.
But we still want to experiment with offloading pre-blend (not post)
color transformation through the colorop API, which is close to being
accepted upstream. But this requires us to offload post-blend as well.
weston_color_curve_to_3x1D_LUT() currently fails if we detect that
crafting a LUT from the color curve may result in bad precision.
Instead, let's add a boolean param to control if we forbid or not bad
precision. This should allow us to offload post-blend xform through
LUT's.
This also improves the error messages in this function.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Since commit "backend-drm: improve code that chooses output->format", we
changed how b->format (the GBM format from the config file) is used.
There are config options in weston.ini that allow us to ignore the GBM
format set. So what matters to us is which output->format is being used,
and we compute that in drm_output_pick_format_egl() and
drm_output_pick_format_pixman().
So remove these checks that disable underlay planes based on b->format,
keeping only the ones that depend on the output->format selection.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Instead of picking an arbitrary format, let's first ensure that the
format is supported by the renderer.
Also, start choosing formats with alpha channel if we have b->underlay.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
When gl_renderer_display_create() fails, do not change the compositor
capabilities.
The compositor may not abort when that happens, it may simply decide to
fallback to another renderer. So setting anything on failure is wrong.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This goes through all formats available in the EGLConfig's that we
get from EGLDisplay and expose them in a struct weston_drm_format.
Currently backends choose a format for their outputs and hope that
GL-renderer is able to find a compatible EGLConfig. This should help
backends to avoid guessing.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Let's be more more specific and rename the renderer interface function
that returns the supported dma-buf formats. I.e. if we pass a dma-buf
with one of these formats for the renderer, it should be able to import
it.
Next we'll introduce a function to query the rendering formats from
the renderer, so this distinction is important.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
To log vis id, we call:
eglGetConfigAttrib(egldpy, eglconfig, EGL_NATIVE_VISUAL_ID, &value)
p = pixel_format_get_info(value)
The problem is, EGL_NATIVE_VISUAL_ID represents a DRM format only on
GBM platform. So for other platforms we are calling
pixel_format_get_info() with values that are not DRM formats.
Avoid calling pixel_format_get_info() when the platform is different
from GBM, and log only the hex value in such case.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
No behavior change, just to make things easier for next commits. They
will need struct gl_renderer *gr in print_egl_config_info().
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Currently when we have a blend-to-output color transformation, we have a
16FP shadow buffer representing the blending space. Then we blit from
that to the primary plane fb, which is a regular buffer (fixed-point,
not 16bpc).
The shadow buffer needs to be 16FP because the blending space is linear
with relation to light. So it needs more bits for encoding.
In the next patches we enable the option to offload the blend-to-output
color transformation to KMS, so we'll need the primary plane fb to be
of a 16FP format. In order to do that, we need to be able to find EGL
configs with float-point formats. In this patch we enable that.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
The plugins cms-static and cms-colord have been deprecated and removed
from our code. They were the only thing holding set_gamma() from being
removed. So remove set_gamma() from the code.
Users can have the same results tweaking the output color profile that
they use.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Our window decor uses cairo-xcb. cairo-xcb stores xcb_connection_t
internally and uses them as kind of a hash key for internal bookkeeping.
This needs to be torn down with a cairo_device_finish, when the last
cairo surface is destroyed, and we are not properly handling that.
Because of this weston bug, if the Xwayland server dies, is restarted,
and the weston X window manager gets the same xcb_connection_t pointer
value for a new connection that it had for a previous connection,
cairo-xcb will use stale state and crash.
Weston is used in some places (like Mesa CI) where Xwayland crashes are
more common than one might usually expect, and weston needs to be robust
against these failures. It's ok to have no window frames in xwl in these
cases, because nobody is interacting with the windows.
The '--no-xwm-decorations' command line option will now remove
cairo-xcb from use entirely, so this crash can no longer happen.
We should still fix the bugs in our cairo usage, but I think long term
it's still ok to have a way to disable this and reduce complexity.
Ref #1042
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
As required by the spec when accessing dmabufs from the CPU, see
https://docs.kernel.org/driver-api/dma-buf.html
While effectively a no-op on amd64, this fixes test failures on various
aarch64 devices, including:
- rk3588 (Panfrost, Rock5)
- rk3399 (Panfrost, PineBook Pro)
- Broadcom BCM2712 (V3D, RPi5)
- Qualcomm SDM845 (freedreno, OnePlus6)
Fixes: 303d88448 (tests: client-buffer: Add dmabuf support)
Signed-off-by: Robert Mader <robert.mader@collabora.com>
