This already calls either weston_view_add_transform() or
weston_view_remove_transform() followed by
weston_view_update_transform(), the combination of which will already
force a repaint for those views.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This already calls weston_view_geometry_dirty_internal() and
weston_view_update_transform(), the combination of which will already
force a repaint for those views.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This already calls weston_view_geometry_dirty_internal() and
weston_view_update_transform(), the combination of which will already
force a repaint for those views.
Signed-off-by: Daniel Stone <daniels@collabora.com>
These already call weston_view_geometry_dirty_internal() and
weston_view_update_transform(), the combination of which will already
force a repaint for those views.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Add the Vulkan renderer in the pipewire backend renderer switches.
For now this goes over the pipewire memfd path.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
The captured buffer cannot be just memcpy'ed to the destination as
it might overwrite existing pixels outside of the capture region.
For now switch it to a pixman composition.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
When xdg_toplevel_send_configure is executed, the xdg_toplevel resource
may have already been destroyed, causing Weston to crash.
Signed-off-by: liang zhou <liang.zhou@gehealthcare.com>
Adjust the no-GL jobs to also do no-Vulkan and only create a couple more
to cover disabling the individual renderers.
Copy the hack for obscure LLVM leak reports so that tests can pass in CI
with lavapipe for a Vulkan driver.
Disable vulkan-renderer build on debian lts for now as unsupported.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Example to serve as a reference of a basic Wayland client using
Vulkan with dmabuf. This does not use a traditional Vulkan swapchain
but implements it using imported gbm buffers. Also features use of
linux-explicit-synchronization-unstable-v1 with Vulkan.
Based on weston-simple-dmabuf-egl.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Example to serve as a reference of a basic Wayland client using
Vulkan, contained in a single source file and with a minimal set
of dependencies.
Features incremental present (similar to swap_buffers_with_damage
from EGL) which is not commonly used by other Vulkan demos and is
useful to test the compositor.
Based on weston-simple-egl.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
A Vulkan renderer for weston, based on the GL renderer.
The goal is to impose the least requirements as possible on Vulkan
implementations, as to allow even Vulkan 1.0 (or early development)
drivers to run a Wayland compositor. Any additional features or
extensions are made optional if possible.
Currently supports drm, wayland, x11 and headless backends.
As of this implementation, this is still considered an experimental
renderer.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
None active window might be interpreted from an X point of view as a
transient focus state, and is used by multiple X window managers when
a temporary focus change is in progress, or simply when grabbing the
keyboard.
From Wine side, we translate any active window change to the Win32
application, and handling None active window as an actual window
deactivation and focus loss creates spurious events and an undesired
feedback loop, as apps might react to it.
We still want to be able to detect actual focus loss under an XWayland
session, and having XWayland window manager focus an actual X window
instead will make the distinction possible.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
This just moves gl-borders up to libweston weston_renderer as-is,
with no change in functionality.
This is a preparation step so that other renderers can use the
same interface.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Containining the pre-compiler conditionals inside tiny functions makes
the code easier to read.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
These cases were never meant to exist, but because the harness assumes
all tests must run on all fixtures, we have to return something.
This is a temporary measure to improve readability. Eventually this test
program should be split:
- shm RGB + YUV
- dmabuf RGB without force-yuv-fallback
- dmabuf YUV with and without force-yuv-fallback
or
- shm RGB + YUV
- dmabuf RGB + YUV without force-yuv-fallback
- dmabuf YUV with force-yuv-fallback
or
- shm + dmabuf; RGB + YUV without force-yuv-fallback
- dmabuf YUV with force-yuv-fallback
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The implementation got removed already and we can just check
the color_model now.
Fixes: 51ed256d (libweston: Replace pixel format's sampler_type with color_model enum)
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Forcing the fallback paths for YUV formats. This will allow us
to test these paths on CI now that llvmpipe supports all tested
formats natively.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Update a comment explaining what we may do in the future when
cmsSmoothToneCurve() fails.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
If we're shutting down, moving surfaces to a different output will not
be profitable. Just clear out the output mask entirely and return early.
This specifically avoids the following issue seen with the Wayland
backend when shutting down:
- outputs destroyed
- colour manager destroyed
- seats destroyed
- pointer destroyed
- sprite view destroyed
- find new output for the sprite view
- update colour profile for the sprite view
- neither the view nor the compositor has any outputs left
- try to use the stock sRGB transfer
- oops, no colour manager
Signed-off-by: Daniel Stone <daniels@collabora.com>
Since "color: do not use color steps for non-optimized pipelines",
WESTON_COLOR_MAPPING_TYPE_3D_LUT became unused. So drop it from our
code.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
For non-optimized pipelines, stop using the color steps (pre curve,
color mapping and post curve). Instead, make use of the
xform->to_shaper_plus_3dlut() vfunc.
In this patch we add a bool to signalize that the steps are valid (for
optimized pipelines) or not. If not (non-optimized ones), the vfunc must
be used.
This brings flexibility for the renderer/backend implementing the xform.
For now we only implement xform's in the GL-renderer, and this has no
behavior changes. It should be relevant when we implement the xform in
our DRM-backend, see commit "color: add to_shaper_plus_3dlut() vfunc to
struct weston_color_transform".
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This function allow us to get a shaper (3x1D LUT) + 3D LUT that is
equivalent to a certain xform.
With that, we allow backend/renderer that are not capable of handling
the color steps of the xform to fallback to something else.
E.g. when we introduce the code to offload color xform to KMS using the
DRM-backend, we'll depend on the driver/hardware implementing the color
steps. With this patch, DRM-backend should be able to fallback to a
shaper (3x1D LUT) + 3DLUT, color operations that should be commonly
supported by drivers/hardwares.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Up to now, when we were able to optimize a color pipeline, we'd delete
xform->cmap_3dlut. In such cases, we'd have a pre curve, color mapping
and post curve that Weston recognizes and implements in the shaders. So
there was no need to use xform->cmap_3dlut.
But at some point we'll try to offload such color transformations to our
DRM-backend, and we are not in control of what color operations the
hardware/driver are capable of. In such case, we may want to use the
fallback LCMS xform (xform->cmap_3dlut) and decompose it into a shaper
(3x1D LUT) + 3D LUT, as such operations should be commonly supported
by hardwares/drivers.
This shows that using the optimized pipeline or not should be a
renderer/backend decision. So do not delete xform->cmap_3dlut even when
we optimize the pipeline.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Change this function signature to look similar to
gl_color_curve_lut_3x1d(), as they do similar things.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
We are filling a struct gl_renderer_color_mapping in this function,
so rename to better reflect that.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This test has only supported the GL renderer, with a must pass list of
formats which matches what the GL renderer advertises and supports.
This commit prepares the test to support other renderers by moving the
must pass list to the test setup declaration, so that it can be defined
per renderer. This is in preparation to add more renderers here as a
followup.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
As I found myself writing these for a MR think it would better
to have to easily available to point people to.
Another small change is that since c706e1f8c8 we no longer
default subscribe to drm-backend for the flight recorder so update docs
as well. Combined with this new file should actually explain better how
to make use of it.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
