Fix a typo. No CM functional change, just redirect LCMS error
into created cmsContext which output into weston log.
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
This is probably the simplest case to demonstrate how to use
WESTON_EXPORT_FOR_TESTS.
Previously, vertex-clip test re-built vertex-clipping.c for itself. Now
it directly links in gl-renderer.so instead as that is where
vexter-clipping.c gets built into for actual use. This probably will not
work for any installed program, but luckily tests are never installed,
so Meson makes sure the DSO is found.
Unfortunately we cannot remove the definition of dep_vertex_clipping
yet, because clients/cliptest.c needs it.
This makes vertex-clip test depend on GL-renderer, but that is where the
code is really used.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Although weston_compositor_run_key_binding() is called when the current
keyboard grab is default_grab or input_method_grab, swallowing the key
event is processed only on default_grab. As a result key events that
should be swallowed are sent to the input method unexpectedly.
For example, when a user press `Super + s` on weston-editor to take a
screen shot, `s` will be unexpectedly entered to the text area.
I confirmed such behaviour with weston-simple-im and fcitx5-5.0.10.
It doesn't occur with weston-keyboard because it doesn't install
keyboard grab.
Signed-off-by: Takuro Ashie <ashie@clear-code.com>
Use 3D LUT for color mapping.
For category CMLCMS_CATEGORY_INPUT_TO_BLEND use transform which has
3 profiles: input, output and light linearizing transfer function.
For category CMLCMS_CATEGORY_INPUT_TO_OUTPUT use input and output profiles +VCGT.
For category CMLCMS_CATEGORY_BLEND_TO_OUTPUT use output inverse EOTF + VCGT.
Co-authored-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Graeme sketched a linearization method there:
https://lists.freedesktop.org/archives/wayland-devel/2019-March/040171.html
Sebastian prototyped there:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14/commits
Thanks to Pekka for great simplifications in implementation, like the xyz_dot_prod()
Quote: "should help untangle lots of the multiplications and summations by saying
we are computing dot products, etc".
The approach was validated using matrix-shaper and cLUT type of profiles.
If profile is matrix-shaper type then an optimization is applied.
The extracted EOTF is inverted and concatenated with VCGT, if it is availible.
Introduce function cmlcms_reasonable_1D_points which would be shared between
linearization method and number of points in 1DLUT for the transform.
Co-authored-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Add to search parameter cmlcms_category, input and output profiles,
and render intent for output which would be used for both profiles.
Add common function setup_search_param for every category.
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
The stock profile would be used when client or output
do not provide any profile or unaware of color management.
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
1. The cmlcms_category is used to identify the purpose of transform:
- CMLCMS_CATEGORY_INPUT_TO_BLEND
- CMLCMS_CATEGORY_BLEND_TO_OUTPUT
- CMLCMS_CATEGORY_INPUT_TO_OUTPUT
2. Added following fields to cmlcms_color_profile:
- output_eotf - If the profile does support being an output profile and it
is used as an output then this field represents a light linearizing
transfer function and it can not be null. The field is null only if
the profile is not usable as an output profile. The field is set when
cmlcms_color_profile is created.
- vcgt - VCGT tag cached from output profile, it could be null if not exist
- output_inv_eotf_vcgt - if the profile does support being an output profile and it
is used as an output then this field represents a concatenation of inverse
EOTF + VCGT, if the tag exists and it can not be null.
3. Added field cmsHTRANSFORM to cmlcms_color_transform.
It is used to store LCMS optimized pipeline.
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
The following GL extensions provide support for shaders CM:
-GL_OES_texture_float_linear makes GL_RGB32F linear filterable.
-GL ES 3.0 provides Texture3D support in GL API.
-GL_OES_texture_3D provides sampler3D support in ESSL 1.00.
If abovesaid is supported then renderer sets flag WESTON_CAP_COLOR_OPS
which means that all fields in struct weston_color_transform are
supported, for example, 1DLUT and 3DLUT.
Use GL_OES_texture_3D to implement 3DLUT function which
uses trilinear interpolation for pixel processing or bypass as is.
Quote from https://nick-shaw.github.io/cinematiccolor/luts-and-transforms.html
"3D LUTs have long been embraced by color scientists and are one of
the tools commonly used for gamut mapping. In fact, 3D LUTs are used
within ICC profiles to model the complex device behaviors necessary
for accurate color image reproduction".
Quote from https://developer.nvidia.com/gpugems/gpugems2/part-iii-high-quality-rendering/
chapter-24-using-lookup-tables-accelerate-color
is about interpolation: "By generating intermediate results based
on a weighted average of the eight corners of the bounding cube,
this algorithm is typically sufficient for color processing,
and it is implemented in graphics hardware".
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Introduce shader color mapping identity and 3D LUT.
Shader requirements struct uses union for color mapping
to prepare the place for 3x3 matrix.
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Introduce 3D LUT definition as part of Weston
color transform struct. A 3D LUT is a LUT containing
entries for each possible RGB triplets.
Co-authored-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
We can end in `subsurface_committed()` in different scenarios
without the surface having an attached buffer. While setting
the mapped state to `true` in that case doesn't matter for
that (sub)surface itself, it triggers its own child subsurfaces
to get mapped when they shouldn't.
Closes https://gitlab.freedesktop.org/wayland/weston/-/issues/426
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Many years ago (2014) systemd-logind was brought into libsystemd.
We've supported old versions of systemd-logind ever since.
Let's remove support for old versions of systemd-logind before the
merge for a tiny code simplification.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Zoom is a neat trick, but in its current form it's very hard to test
and maintain.
It also causes output damage to scale outside of the output's boundaries,
which leads to an extra clipping step that's only necessary when zoom
is enabled.
Remove it to simplify desktop-shell and compositor.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
The spec states:
> Because buffer transformation changes and damage requests may be
> interleaved in the protocol stream, it is impossible to determine
> the actual mapping between surface and buffer damage until
> wl_surface.commit time. Therefore, compositors wishing to take both
> kinds of damage into account will have to accumulate damage from the
> two requests separately and only transform from one to the other after
> receiving the wl_surface.commit.
For subsurfaces in sync mode, arguably the same is the case until the
cached state gets applied eventually. Thus, in order to keep complexity
to a sane level, just accumulate buffer damage and convert it only
when the cached state gets applied.
This mirrors how other compositors like Mutter implement cached damage
and what the spec arguably should demand.
Closes https://gitlab.freedesktop.org/wayland/weston/-/issues/446
Signed-off-by: Robert Mader <robert.mader@collabora.com>
These formats are useful because they are often easier to produce
on CPU than half-float formats, and abgr16161616 has both >= 10bpc
color channels and adequate alpha, unlike abgr2101010.
The 16-bpc textures created from buffers with these formats require
the GL_EXT_texture_norm16 extension.
As WL_SHM_FORMAT_ABGR16161616 was introduced in libwayland 1.20,
update Weston's build requirements and CI.
The formats also needed to be registered in the pixel format table,
and defined in a fallback path if recent libdrm is not available.
Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
Specifically log if there were no suitable planes for us to use, or if
we tried to place it on a plane but were told no by the kernel.
Signed-off-by: Daniel Stone <daniels@collabora.com>
There's no real reason for these to be separate now that the eligibility
checks have been moved up so we don't call them unless it makes sense.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We just copy the SHM buffer straight into a separately-allocated GBM BO,
so no need to take a reference on the buffer itself or keep it from
being released.
All drm_output_try_view_on_plane really does at this point is to call
the prepare_*_view function for the requisite plane type, and take a ref
on the weston_buffer from the client. Given that we don't need to keep
the client buffer alive, we can short-circuit
drm_output_try_view_on_plane, and instead just call
drm_output_prepare_cursor_view directly when we have a cursor plane.
This also makes it easier to just remove drm_output_try_view_on_plane in
following patches when we merge the overlay/scanout plane path into one.
Doing so gives us two clearly-separated paths: one for copying a SHM
client buffer into a cursor, and another for directly scanning out
client content.
Signed-off-by: Daniel Stone <daniels@collabora.com>
At some point this got hobbled, such that NO_PLANES and
NO_PLANES_ACCEPTED became the same thing, so we can just check if the
returned plane_state is NULL or not.
Signed-off-by: Daniel Stone <daniels@collabora.com>
For views which cover the entire output, we always attempt to place them
on the primary plane, to avoid a situation where we place a fullscreen
view into an overlay plane and then have to disable the primary plane,
which doesn't always work.
Move this check earlier, so we don't consider overlay planes to be
candidates for fullscreen views. This check should be changed in future
to only filter for opaque views, but that's for another time.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We shouldn't get down into trying to place a view on a cursor plane if
these checks are not met, so change them to asserts rather than early
returns.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When we introduced support for variable zpos, we did so by filtering the
list of acceptable planes and then creating a separate zpos-ordered
list. Now that the planes are already zpos-sorted in the backend list,
and we have more early filtering, we can replace this with a single
plane-list walk.
Signed-off-by: Daniel Stone <daniels@collabora.com>
For better or worse, cursor planes can only be used by uploaded SHM
buffers right now, so ignore them when we're calculating the acceptable
plane mask for client dmabufs.
Signed-off-by: Daniel Stone <daniels@collabora.com>
If we're in renderer-only mode, we can only use the renderer and the
cursor plane. Don't even try to import client buffers as it makes no
sense.
Signed-off-by: Daniel Stone <daniels@collabora.com>
If we have a SHM buffer, it can only go into a cursor plane - and only
then if it's of the right format.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Each output is hardcoded to the use of a single 'special' (primary or
cursor) plane; make sure we don't try to steal them from other outputs
which might not be happy to discover that we've taken it off them.
Signed-off-by: Daniel Stone <daniels@collabora.com>
GBM is how we import all our client content into DRM FBs, so don't try
anything other than renderer-only without it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
It's possible to write this with a few less twisty special cases. Tested
manually with a randomly-distributed input tree as well as manually
trying to hit special cases around first/last entries.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This ensures that users that previously set the option explicitly will also have
a chance to notice the deprecation.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
weston-launch will be removed in a future release as this feature has
been offloaded to libseat and seatd-launch. Print an early deprecation
warning to give existing users time to migrate.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
Transforming the scanout damage by the zoom will result in rectangles
outside of the display, and some with negative co-ordinates. This makes
at least some drivers unhappy (tested on vmware), and the page flip fails,
and weston hangs indefinitely.
Clip the damage to the output so we don't fall down.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Rename the build option to "deprecated-backend-fbdev" so that a
previously configured build dir doesn't retain the old setting.
This is consistent with the existing "deprecated-wl-shell" option.
Make the option default to "false".
Print a warning when fbdev is force-enabled.
Signed-off-by: Simon Ser <contact@emersion.fr>
References: https://gitlab.freedesktop.org/wayland/weston/-/issues/581
The invariant is clearly documented in code comments, but the code
failed to ensure it in all cases. Fix it.
There is one very specific protocol sequence triggered by a development
version of the Wine Wayland driver when Chrome (win64 app) is switched
from window to fullscreen and then back by pressing F11 key. The switch
back triggered
weston: ../libweston/color.c:217: weston_paint_node_ensure_color_transform: Assertion 'it->surf_xform_valid == false' failed
For some reason, that specific protocol sequence causes
weston_compositor_build_view_list() to create a transient second view
for a sub-surface. In the Chrome traces, I have seen that happen twice
per run. The first time it works, the old view gets immediately
destroyed. The second time (during un-fullscreening) a new transient
view is create and then it fails the invariant check.
The fix is in weston_paint_node_create() which is supposed to ensure the
invariant. However, it went through the (new) view's paint node list,
which will not contain paint nodes from other views. In hindsight this
is an obvious bug, but perhaps all views having exactly one associated
surface each somehow confused the author. Since the invariant is about
surface+output, go through the surface's paint node list instead. That
list contains all the relevant paint nodes by definition.
Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/568
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Vitaly Prosyak
Pekka Paalanen
Takuro Ashie
Marius Vlad
Robert Mader
Derek Foreman
Manuel Stoeckl
Daniel Stone
Kenny Levinsen
Simon Ser