The sRGB expected display behavior uses the pure power-law with exponent
2.2, not the two-piece sRGB transfer function.
cmsCreate_sRGBProfileTHR() used the two-piece TF, now we use the proper
display TF.
This is particularly meaningful when implicit sRGB content is converted
to HDR formats, in order to maintain the stimuli reproduction near zero.
cmlcms_send_image_desc_info() is already sending this, it doesn't need
fixing.
Changing the curve also changes the error tolerances. The change is
theoretically a no-op, but the curve and its inverse and temporary
rounding add error. The new curve is more prone to error, so it is not
surprising we need to raise the tolerance. The color transformation does
end up as power-2.2 analytical form and I do not think it is ever
lowered to a LUT in alpha-blending test, so there is no obvious fix
improving the accuracy. The worst case point in alpha-blending still
occurs at the very same point as before.
The test reference images are updated for the same reason, they would
fail otherwise.
Both alpha-blending and color-icc-output contain the same sRGB-optical
sub-test, hence the same error tolerance.
It is surprising to have to increase the ICC roundtrip error tolerance
in color-icc-output test, given that the curves are passed as parametric
to LittleCMS, and adobeRGB case works with the old tolerance even. I did
not investigate further.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Refactoring data about a thing into one place to simplify code.
Also this function is never expected to fail, so no need for the boolean
return.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Collect all information of an item into a table entry in one place. Will
be easier to add new items this way.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The sRGB display uses a power-2.2 transfer characteristic. These enum
values refer to the two-piece sRGB transfer function instead, so they
should not be named "EOTF".
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
When I was changing the stock sRGB profile from the two-piece TF to the
power-2.2 TF, all CLUT tests in color-icc-output started failing. It
appeared that cmsSmoothToneCurve() caused an already monotonic curve to
become non-monotonic, and then failing its own monotonicity test. I can
only guess that it might have something to do with the power-2.2 curve
having nearly zero derivative near zero.
As a workaround, check if the curve is already monotonic and don't
bother smoothing in that case. This allows the tests to pass in the
future where the sRGB profile has been changed.
OTOH, increasing smoothing_param up to 10.0f still did not help.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
As DRM_FORMAT_P030 was introduced in some later libdrm (2.4.114)
version add a fallback for it to allow building on systems which do
not have that libdrm version.
Fixes 4f4011d79e ("pixel-formats: Add P030")
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
As spotted in the wild, building without Vulkan still picks up
Vulkan headers. This drops the VkInstance alltogether as that's not
really used.
As this file appears to be pulling XCB headers guard them as well.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
When I changed the weston_matrix implementation to linalg-4.h, I broke
the type computations: they were getting reset instead of accumulated.
This manifested with the desktop-shell feature where one can arbitrarily
rotate the windows. A rotated window triggered an incorrect matrix type,
which then did not ignore the surface opaque region as it should have.
That caused rendering artifacts on all renderers.
Fixes: 3fefb5ba44
Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/1031
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
It has no more callers, and hasn't done what its name implies for a very
long time.
Remove it.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
weston_view_damage_below() does nothing but schedule a repaint, and a
repaint will be scheduled in weston_view_geometry_dirty_internal() anyway,
so remove the extra call.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Instead of calling weston_view_damage_below(), which only schedules a
repaint, call weston_view_schedule_repaint() instead.
The result is the same, but the code is less confusing.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Update transform only does something if we've called
weston_view_geometry_dirty_internal() previously to set the dirty flag.
weston_view_damage_below() just schedules a repaint, and
weston_view_geometry_dirty_internal() will already have done that.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
weston_view_damage_below() has done nothing but schedule a repaint for a
long time now.
weston_view_destroy() will trigger the repaint without forcing it here.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
kiosk-shell/xdg-shell is the (more) modern approach, so let's inform
users that fullscreen-shell is going way.
This also adds an explicit dependency of shell-fullscreen for
screenshare. With this change, both screenshare and fullscreen-share
are disabled by default.
Fixes: #848
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
There is no valid reason for anyone to call this.
True surface damage is already handled when surfaces are committed. View
damage is already handled through any per-view manipulation which would
generate damage. There is thus no reason for anyone to ever call this.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The content-protection state is a property of the output, as it affects
quite a bit of output state, as well as things like whether or not
recording is possible.
Instead of damaging surfaces for content-protection state changes,
damage each output for which the protected surface is relevant.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When we change the subsurface order, the surface itself has not received
any damage: what's been damaged is the views. Place the damage where it
should be, as the act of moving the view within the view list is where
the damage originates from.
Signed-off-by: Daniel Stone <daniels@collabora.com>
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>
