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>
Commit 0e4f097d broke opaque regions, and since then weston will waste
time rendering occluded areas.
I think this is because we're taking the intersection of the opaque
and scissor regions even when the scissor region isn't enabled.
An easy test is to turn on triangle fan debugging with the gl renderer,
then run weston-simple-damage and move another opaque application such as
weston-terminal over it.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Leak found running drm-smoke-test with ASan.
Do not forget to free the launcher before returning when we can't open
the launcher fd. Also, just set 'out = launcher' after all error paths,
otherwise we give the caller a stale pointer.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
weston_touch_destroy(), which is called from weston_seat_release(),
asserts that all its touch devices have been destroyed. The Wayland
backend currently destroys the touch devices ... immediately after
calling weston_seat_release().
Invert the ordering so that touch devices are destroyed first and we
don't trip over the assert.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When EGL initialization fails (failure to create a GLES3 or GLES2
context) we will end up calling gbm_device_destroy() twice, once
in init_egl() and once in the drm_backend_create() error path.
Given that we should also take care of properly destroying the gbm
device when we don't have any inputs for instance, mark the gbm device
as NULL to avoid calling gbm_device_destroy() once more when destroying
the DRM-backend.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Replaces potential corruption signal emit call sites with the more safer
weston_signal_emit_mutable().
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This uses the more safer version of signal emission to avoid a potential
crash when the output is destroyed that will follow a surface/view
destruction for which it has a listener attached (to the output_destroy
signal).
Fixes: #734
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This avoids crashes due to removal of notification listeners from within
invocations of other listener callbacks in the same signal emission.
Fixes: #415
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Walking the format/modifier list to try to find out if our FB is
compatible with the plane is surprisingly expensive. Since the plane's
capabilities are static over the lifetime of the KMS device, cache the
set of planes for which the FB is theoretically
format/modifier-compatible when it's created, and use that to do an
early cull of the set of acceptable planes.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When we first create a drm_fb from a weston_buffer, cache it and keep it
alive as long as the buffer lives. This allows us to reuse the gbm_bo
and kernel-side DRM framebuffer, rather than constantly creating and
destroying them at every repaint. The overhead of doing so (e.g. MMU
updates) can be significant on some platforms.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Currently each drm_fb takes a reference on a client buffer it wraps.
This prevents us from being able to reuse a drm_fb in multiple places
(e.g. two views of the same client buffer) simultaneously, or even back
to back.
Move the buffer reference to the plane state, as preparation for
allowing drm_fb to be cached inside the weston_buffer.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Currently we take a reference on the underlying client buffer every time
we materialise a drm_fb from a view, and release it when the drm_fb is
destroyed. This means that we need to create and destroy a drm_fb every
time we want to use it, which is pathologically unperformant on some
platforms.
To start working towards being able to cache drm_fb, only take the
reference when we apply it to a plane state.
Signed-off-by: Daniel Stone <daniels@collabora.com>
No sense walking the plane list every frame if we can't use it because
it's neither a SHM buffer nor a client buffer we can directly import as
a framebuffer.
Signed-off-by: Daniel Stone <daniels@collabora.com>
If we still have a pending idle timer when the compositor is being
destroyed, make sure to free it first.
Signed-off-by: Daniel Stone <daniels@collabora.com>
EGLNativeWindowType can be a lot of different things, including a
pointer which an XID is not. Explicitly cast it through uintptr_t so we
don't throw build warnings either way.
Signed-off-by: Daniel Stone <daniels@collabora.com>
In commit "libweston: add initial dma-buf feedback implementation" we've
added initial support to dma-buf feedback, but it was not using the
feedback from DRM-backend to add useful per-surface feedback.
In this patch we add this. The scanout tranche of the per-surface
feedback is based on the union of formats/modifiers of the primary and
overlay planes available. These are intersected with the
formats/modifiers supported by the renderer device.
Also, it's important to mention that the scene can change a lot and we
can't predict much. So this patch also adds hysteresis to the dma-buf
feedback. We wait a few seconds to be sure that we reached stability
before adding or removing the scanout tranche from dma-buf feedback and
resending them. This help us to avoid spamming clients and leading to
unnecessary buffer reallocations on their end.
Here's an example of what we want to avoid:
1. We detect that a view was not placed in a plane only because its
format is not supported by the plane, so we add the scanout tranche
to the feedback and send the events.
2. A few milliseconds after, the view gets occluded. So now the view
can't be placed in a plane anymore. We need to remove the scanout
tranche and resend the feedback with formats/modifiers optimal for
the renderer device. The client will then reallocate its buffers.
3. A few milliseconds after, the view that was causing the occlusion
gets minimized. So we got back to the first situation, in which the
format of the view is not compatible with the plane. Then we need to
add a scanout tranche and resend the feedback...
This patch is based on previous work of Scott Anderson (@ascent).
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Add enum try_view_on_plane_failure_reasons to help us to keep track of
the reason why promoting view to a plane failed. We also add a variable
to struct weston_paint_node so that we can update this information in
each output repaint.
This will be used in the next commits, in which we add proper surface
dma-buf feedback support.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
This adds the initial dma-buf feedback implementation, following the
changes in the dma-buf protocol extension.
The initial dma-buf feedback implementation gives support to send
default feedback and per-surface feedback. For now the per-surface
feedback support is very basic and is still not implemented in the
DRM-backend, what basically means that KMS plane's formats/modifiers are
not being exposed to clients. In the next commits of this series we add
the DRM-backend implementation.
This patch is based on previous work of Scott Anderson (@ascent).
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
This just documents why we can be sure that
renderer->get_supported_formats() is set in bind_linux_dmabuf().
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
It simply returns the number of format/modifier pairs in the array. This
will be useful for the next commits, in which we add support for dma-buf
feedback.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Add function to query the DRM device given an EGLDisplay. It is the
device being used by the compositor to perform composition.
This will be useful in the next commits of this series, where we add
support for dma-buf feedback.
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Errors happening to devices being added or removed shouldn't fail
silently so exit if any of that happens.
Sprinkle some debug logs for other cases as well.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
Add API to set an output's color profile. This new function can also be
called while the output is enabled. This allows changing the output
color profile even at runtime if desired.
color-noop has no way of creating weston_color_profile objects, so it
just asserts that no color profile is set.
color-lcms does not yet implement taking the output color profile into
account, so for now it just fails everything if a profile is set.
weston_surface_color_transform_fini() was previously used only prior to
freeing the struct, but now it is used also to just clear the struct,
hence it needs to reset the fields.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Move the code into a new function that either succeeds in setting all
the color transformations or does not change anything. This will be
useful when implementing output color profiles changes while the output
is enabled.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This function will be useful for Weston to load output ICC profiles from
weston.ini.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Roughly speaking, a color profile describes the color space of content
or an output. Under the hood, the description includes one or more ways
to map colors between the profile space and some standard profile
connecting space (PCS).
This object is not called a color space. A color space has a unique
definition, while a color profile may contain multiple different
mappings depending on render intent. Some of these mappings may be
subjective, with an artistic touch.
When a source color profile and a destination color profile are combined
under a specific render intent, they produce a color transformation.
Color transformations are already preresented by weston_color_transform.
This patch adds the basic API for color profile objects. Everything
worthwhile of these objects is implemented in the color managers:
color-noop never creates these, and in color-lcms they are basically a
container for cmsHPROFILE, the Little CMS object for color profiles.
Color profile objects will not be interpreted outside of the color
managers, unlike color transformations.
For a start, the color manager API has one function to create color
profiles: from ICC profile data. More creation functions for other
sources will be added later.
The API has errmsg return parameter for error messages. These are not
simply weston_log()'d, because CM&HDR protocol will allow clients to
trigger errors and the protocol handles that gracefully. Therefore
instead of flooding the compositor logs, the error messages will
probably need to be relayed back to clients.
Color-lcms is expected to create a cmsHPROFILE for all kinds of color
profiles, not just for those created from ICC profile data. Hence,
color-lcms will fingerprint color profiles by the MD5 hash which Little
CMS computes for us. The fingerprint is used for de-duplication: instead
of creating copies, reference existing color profiles.
This code is very much based on Sebastian Wick's earlier work on Weston
color management, but structured and named differently.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
These formats will be eventually be useful for color managed clients
using wl_shm that wish to submit buffers encoding high dynamic range
images.
While the minimum requirement for linearly filterable half float
textures is GL ES 2.0 + GL_OES_texture_half_float_linear, to keep
the code simple, this commit only enables the new formats when
the requirements for color management (notably including GL ES 3.0
and GL_EXT_color_buffer_half_float) are available.
Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
This fixes the tear-down and the destroying part in case RDP back-end
couldn't be initialized. The first issue is the rdp_output which will
not be created in some circumstances (can't open the socket for
instance) and requires a guard check, and secondly, the
rdp_head being created above of that, wasn't removed and tripped an
assert when destroying the compositor instance.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Adding these formats makes it possible for clients using wl_shm to
submit buffers with 10 bits per pixel, and thus (if Weston is
configured with an xrgb2101010 frame buffer) display more precise
colors on some computer monitors.
Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
The struct wayland_input objects tracking the outer compositor's
wl_seats are now properly destroyed when the wayland backend is.
Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
The wl_display_roundtrip call was originally introduced to let the
display_add_seat function wait until a wl_seat.name event was received.
This change replaces the wl_display_roundtrip call with an
asynchronous, nonrecursive equivalent. Now a wl_display.sync callback
is used to delay the final steps of adding a seat until one protocol
roundtrip has occured/the name has been received.
Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
My reading of the GL spec is that a dmabuf becomes a sibling to the
EGLImage created from it, and that all updates to the dmabuf will be
propagated to the EGLImage.
A rebind is still required every time the dmabuf content changes,
but this should be satisfied by gl_renderer_attach(), which does
a rebind when the buffer is commit.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
So, turns out the GL implementation is allowed to destroy EGLImage
sources if this isn't set. Apparently none we've ever been tested on do
this, but it looks like we should be setting this anyway.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
If we're not in a session we can fall back to sd_uid_get_display() to
find the user's primary session.
This allows launching weston from an ssh session or as a systemd
user service if a viable session is available.
It also more closely follows how libseat finds the session. The libseat
launcher can already do these things, so this change makes these
features common to both launchers.
Based on a patch by Sjoerd Simons <sjoerd.simons@collabora.com>
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Reported in !179 adding weston_output_repaint_failed resets the output
Co-authored-by: Daniel Stone
Co-authored-by: Julius Krah
Signed-off-by: n3rdopolis <bluescreen_avenger@verizon.net>
If two or more clients were running and the one that was focused when
weston itself lost keyboard focus was killed, weston would crash.
This is because commit 85d55540cb changed the way we handle saved keyboard
focus when we lose focus, and did so in such a way that the saved keyboard
focus listener could be removed from the surface destroy signal list
during the emit of the surface destroy signal. This corrupted the list
and led to a NULL pointer dereference.
Fix this by using a boolean flag to determine whether we should obey the
saved keyboard focus. We can set this safely in cases where
removing the listener would cause a crash.
Fixes#138
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Adds a Pixman format field to the pixel format table, and
adjusts the shm format handling code in the Pixman renderer
to use this table.
Pixman formats have been registered only for specific 565, 8888,
and 2101010 layouts, as these have corresponding DRM format codes
and are commonly used.
Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
EGL_KHR_partial_update can be implemented independently of
EGL_EXT_buffer_age so we handle each case seperately.
Signed-off-by: Ben Davis <ben.davis@arm.com>
Signed-off-by: Dennis Tsiang <dennis.tsiang@arm.com>
weston_output_enable() initializes the list, but weston_output_release()
maybe be called even if the output was never enabled, triggering the
assert due to uninitialized (actually NULL) list head.
This can be triggered with a bad weston.ini, for example using an
invalid output transform value.
Check in weston_output_disable() instead, but because it too may be
called for non-enabled output, only if it was actually enabled.
Fixes: 1a4f87dec5
"libweston: introduce weston_paint_node"
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Since commit "drm-formats: save result of intersection in the first
array", every block of code where weston_drm_format_array_create() and
destroy() are being called could use init() and fini() instead.
Remove these two functions from the API to make it leaner. This patch
also modifies the code that depends on these functions to use init() and
fini().
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
In the current API, we have some set operations: join, intersect and
subtract. Both join and subtract receives two DRM format arrays and save
the result in the first one.
For the intersection we have a slightly different approach, what makes
the API weird. We don't save the result in the arguments, instead we
return a new array with the result.
Modify weston_drm_format_array_intersect() in order to make it similar
to the other two set operations.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
EGL's native display type is not particularly well defined; in
gl-renderer we get around this by always treating it as a void *, since
for all the platforms we care about it's a pointer - gbm_device,
wl_display, or Display *.
The surfaceless platform doesn't care what the native display is (since
it doesn't have one by definition), so just use NULL instead of what may
be either NULL or 0 depending on environmental factors.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The API expects uintptr_t (good!), but we're passing an unsigned long
here. Make the conversion explicit.
Signed-off-by: Daniel Stone <daniels@collabora.com>
pointer/touch drag-n-drop operations could happen if there's no keyboard
hooked up or when it is unplugged.
Fixes: #235
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
And ultimately, fail to start when there are no input devices on the
system. Patchs adds consistency to touch/pointer initialization to
return -1 in case same thing happens.
Further more, when the device is not created we can't assume to retrieve
a valid one from a libinput_device so guard against it. This takes care of
hot-plugging situations when we couldn't create the (keyboard) device,
or when removing it.
Fixes: #117, #402, #485
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
Some graphics drivers (currently at least VMware and AMD) will give a 0
timestamp for the atomic mode flip completion event when turning off
the display. This causes us to trip an assertion in
weston_output_frame_finish() because the clock jumps backwards, which
isn't a condition the presentation feedback code should be dealing with.
This is a good assertion and we'd like to keep it. And there's some
expectation that this is buggy behaviour in the graphics drivers that will
be fixed at some point.
Pragmatically speaking though, there's nothing productive we can do with a
correct timestamp for the display shutdown. So let's just flag the
event sent for DPMS off as invalid so presentation feedback doesn't have
to worry about it, and the assert doesn't fire.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
weston_frame_callback is needed primarily to store the doubly-linked list link,
but it can be also retrieved by using the wl_resource_get_link() function.
This removes an extra heap allocation per every wl_callback object.
Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
Conditionally build support when libdrm is at least 2.4.107 to make use
of it. Plug it in when printing out the buffer information.
With this in, we add a hard dependecy for libweston to link against
libdrm.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Potential failures when creating the EGL image could cause an incorrect
number of num images (num_planes > num_images). With this change
egl_image_unref() requires an additional check to avoid any potential NULL
derefs when cleaning up. We do it straight in egl_image_unref() instead
of adding guards all over the necessary parts.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
As observed on some platforms, importing known DMA buffers can cause
failures, leading to an attempt of destroyng an EGL image not set. This patch
resets the num_images such that loop becomes inert when destroying the
DMA buffer, and avoids passing an egl image to it.
The initial import doesn't have this issue as it sets the num_images in
case it succeeds. This also corrects the assumption that the num_images
were 0 at that point which, if the initial import succeded, was actually set
to 1.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
The wayland.c actually include 'xdg-shell-client-protocol.h' instead of
the server one, so fix it. Otherwise, it's possible to get build failure
due to race condition.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Daniel Stone <daniels@collabora.com>
[daniels: Found in OpenEmbedded/Yocto source.]
Fixes a minor leak due to launcher-libseatd:
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7f15664e5037 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.6+0xaa037)
#1 0x7f156305c59f in zalloc ../include/libweston/zalloc.h:38
#2 0x7f156305c99b in seat_open_device ../libweston/launcher-libseat.c:114
#3 0x7f1563056341 in weston_launcher_open ../libweston/launcher-util.c:79
#4 0x7f156302f1e2 in drm_device_is_kms ../libweston/backend-drm/drm.c:2616
#5 0x7f156302f751 in find_primary_gpu ../libweston/backend-drm/drm.c:2715
#6 0x7f15630309a5 in drm_backend_create ../libweston/backend-drm/drm.c:2970
#7 0x7f15630317ab in weston_backend_init ../libweston/backend-drm/drm.c:3162
#8 0x7f1566025b61 in weston_compositor_load_backend ../libweston/compositor.c:8201
#9 0x7f156640cb9e in load_drm_backend ../compositor/main.c:2596
#10 0x7f156641193c in load_backend ../compositor/main.c:3079
#11 0x7f1566413cc3 in wet_main ../compositor/main.c:3356
#12 0x562ba484b179 in main ../compositor/executable.c:33
#13 0x7f156624fcc9 in __libc_start_main ../csu/libc-start.c:308
But also use the launcher interface to actually close the DRM fd, in
mirror to what weston_launcher_open() does.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Initialize LittleCMS and use it to generate the sRGB EOTF and inverse
curves. Use these curves to define the blending color space as optical
(linear) sRGB by assuming that both content and output color spaces are
sRGB.
As a consequence, this causes Weston to do "gamma correct blending", as
in, blend in light linear space which should avoid distorting colors in
alpha gradients, when color-lcms is active.
This makes use of the 3x1D LUT support added in gl-renderer earlier, and
shows how the color manager is responsible for re-using existing color
transformation objects.
Co-authored-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Use the blending to output color space transformation when blitting from
the shadow to a framebuffer.
This allows the blending and output color spaces to differ as long as
shadow is used, in case a backend does not off-load the color
transformation.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Use the sRGB to output color space transformation when blitting the
borders (decorations) into an output window (nested compositor).
Nested output does not need to be sRGB anymore, as far as the
decorations are concerned.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Use the sRGB to blending color space transformation for the censoring
color fill and triangle fan debug drawings.
This removes the assert that the output's blending space is (non-linear)
sRGB.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This makes weston_color_transform object be able to express
three-channel one-dimensional look-up table transformations. They are
useful for applying EOTF and EOTF^-1 mapping, or, gamma curves. They
will also be useful in optimizing a following 3D LUT tap distribution
once support for 3D LUT is added.
The code added here translates from the lut_3x1d fill_in() interface to
a GL texture to be used with SHADER_COLOR_CURVE_LUT_3x1D for
weston_surfaces.
It demonstrates how renderer data is attached to weston_color_transform
and cached.
GL_OES_texture_float_linear is required to be able to use bilinear
texture filtering with 32-bit floating-point textures, used for the LUT.
As the size of the LUT depends on what implements it, lut_3x1d fill_in()
interface is a callback to the color management component to ask for an
arbitrary size. For GL-renderer this is not important as it can easily
realize any LUT size, but when DRM-backend wants to offload the EOTF^-1
mapping to KMS (GAMMA_LUT), the LUT size comes from KMS.
Nothing actually implements lut_3x1d fill_in() yet, that will come in a
later patch.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This adds shader support for using a three-channel one-dimensional
look-up table for de/encoding input colors. This operation will be useful
for applying EOTF or its inverse, in other words, gamma curves. It will
also be useful in optimizing a following 3D LUT tap distribution once
support for 3D LUT is added.
Even though called three-channel and one-dimensional, it is actually
implemented as a one-channel two-dimensional texture with four rows.
Each row corresponds to a source color channel except the fourth one is
unused. The reason for having the fourth row is to get texture
coordinates in 1/8 steps instead of 1/6 steps. 1/6 may would not be
exact in floating- or fixed-point arithmetic and might perhaps risk
unintended results from bilinear texture filtering when we want linear
filtering only in x but not in y texture coordinates. I may be paranoid.
The LUT is applied on source colors after they have been converted to
straight RGB. It cannot be applied with pre-multiplied alpha. A LUT can
be used for both applying EOTF to go from source color space to blending
color space, and EOTF^-1 to go from blending space to output
(electrical) space. However, this type of LUT cannot do color space
conversions.
For now, this feature is hardcoded to off everywhere, to be enabled in
following patches.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Always when supported, make the fragment shader default floating point
precision high. The medium precision is roughly like half-floats, which
can be surprisingly bad. High precision does not reach even normal
32-bit float precision (by specification), but it's better. GL ES
implementations are allowed to exceed the minimum precision requirements
given in the specification.
This is an advance attempt to avoid nasty surprises from poor shader
precision.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Add a new shader requirements bit input_is_premult which says whether
the texture sampling results in premultiplied alpha or not. Currently
this can be deduced fully from the shader texture variant, but in the
future there might a protocol extension to explicitly control it. Hence
the need for a new bit.
yuva2rgba() is changed to produce straight alpha always. This makes
sample_input_texture() sometimes produce straight or premultiplied
alpha. The input_is_premult bit needs to match sample_input_texture()
behavior. Doing this should save three multiplications in the shader for
straight alpha formats.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Leak found running drm-formats-test with ASan:
==58755==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fae744dbe3a in zalloc ../include/libweston/zalloc.h:38
#2 0x7fae744dbe4e in weston_drm_format_array_create ../libweston/drm-formats.c:44
#3 0x7fae744dd2a2 in weston_drm_format_array_subtract ../libweston/drm-formats.c:410
#4 0x55723c67bed5 in subtract_arrays ../tests/drm-formats-test.c:487
#5 0x55723c67b6bb in wrapsubtract_arrays ../tests/drm-formats-test.c:467
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fae744dbe3a in zalloc ../include/libweston/zalloc.h:38
#2 0x7fae744dbe4e in weston_drm_format_array_create ../libweston/drm-formats.c:44
#3 0x7fae744dd2a2 in weston_drm_format_array_subtract ../libweston/drm-formats.c:410
#4 0x55723c67deca in subtract_arrays_modifier_invalid ../tests/drm-formats-test.c:613
#5 0x55723c67da3d in wrapsubtract_arrays_modifier_invalid ../tests/drm-formats-test.c:593
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fae744dbe3a in zalloc ../include/libweston/zalloc.h:38
#2 0x7fae744dbe4e in weston_drm_format_array_create ../libweston/drm-formats.c:44
#3 0x7fae744dd2a2 in weston_drm_format_array_subtract ../libweston/drm-formats.c:410
#4 0x55723c67c9c0 in subtract_arrays_same_content ../tests/drm-formats-test.c:521
#5 0x55723c67c55b in wrapsubtract_arrays_same_content ../tests/drm-formats-test.c:504
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fae744dbe3a in zalloc ../include/libweston/zalloc.h:38
#2 0x7fae744dbe4e in weston_drm_format_array_create ../libweston/drm-formats.c:44
#3 0x7fae744dd2a2 in weston_drm_format_array_subtract ../libweston/drm-formats.c:410
#4 0x55723c67d1b7 in subtract_arrays_exclusive_formats ../tests/drm-formats-test.c:552
#5 0x55723c67cb23 in wrapsubtract_arrays_exclusive_formats ../tests/drm-formats-test.c:529
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fae744dbe3a in zalloc ../include/libweston/zalloc.h:38
#2 0x7fae744dbe4e in weston_drm_format_array_create ../libweston/drm-formats.c:44
#3 0x7fae744dd2a2 in weston_drm_format_array_subtract ../libweston/drm-formats.c:410
#4 0x55723c67d8d5 in subtract_arrays_exclusive_modifiers ../tests/drm-formats-test.c:584
#5 0x55723c67d31d in wrapsubtract_arrays_exclusive_modifiers ../tests/drm-formats-test.c:561
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 320 byte(s) in 5 object(s) allocated from:
#0 0x7fae74658279 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fae74473bc3 in wl_array_add (/usr/lib/libwayland-client.so.0+0xabc3)
#2 0x7fae74473c10 in wl_array_copy (/usr/lib/libwayland-client.so.0+0xac10)
#3 0x7fae744dbfe0 in add_format_and_modifiers ../libweston/drm-formats.c:108
#4 0x7fae744dd389 in weston_drm_format_array_subtract ../libweston/drm-formats.c:418
#5 0x55723c67d1b7 in subtract_arrays_exclusive_formats ../tests/drm-formats-test.c:552
#6 0x55723c67cb23 in wrapsubtract_arrays_exclusive_formats ../tests/drm-formats-test.c:529
#7 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#8 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#9 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#10 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#11 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#12 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#13 0x55723c680844 in main ../tests/weston-test-runner.c:661
#14 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#15 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 256 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658652 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:164
#1 0x7fae74473b76 in wl_array_add (/usr/lib/libwayland-client.so.0+0xab76)
#2 0x7fae744dc19f in weston_drm_format_array_add_format ../libweston/drm-formats.c:166
#3 0x7fae744dbfb7 in add_format_and_modifiers ../libweston/drm-formats.c:104
#4 0x7fae744dd389 in weston_drm_format_array_subtract ../libweston/drm-formats.c:418
#5 0x55723c67d1b7 in subtract_arrays_exclusive_formats ../tests/drm-formats-test.c:552
#6 0x55723c67cb23 in wrapsubtract_arrays_exclusive_formats ../tests/drm-formats-test.c:529
#7 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#8 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#9 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#10 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#11 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#12 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#13 0x55723c680844 in main ../tests/weston-test-runner.c:661
#14 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#15 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 256 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658652 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:164
#1 0x7fae74473b76 in wl_array_add (/usr/lib/libwayland-client.so.0+0xab76)
#2 0x7fae744dc19f in weston_drm_format_array_add_format ../libweston/drm-formats.c:166
#3 0x7fae744dd3de in weston_drm_format_array_subtract ../libweston/drm-formats.c:426
#4 0x55723c67bed5 in subtract_arrays ../tests/drm-formats-test.c:487
#5 0x55723c67b6bb in wrapsubtract_arrays ../tests/drm-formats-test.c:467
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 128 byte(s) in 2 object(s) allocated from:
#0 0x7fae74658279 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fae74473bc3 in wl_array_add (/usr/lib/libwayland-client.so.0+0xabc3)
#2 0x7fae74473c10 in wl_array_copy (/usr/lib/libwayland-client.so.0+0xac10)
#3 0x7fae744dbfe0 in add_format_and_modifiers ../libweston/drm-formats.c:108
#4 0x7fae744dd389 in weston_drm_format_array_subtract ../libweston/drm-formats.c:418
#5 0x55723c67bed5 in subtract_arrays ../tests/drm-formats-test.c:487
#6 0x55723c67b6bb in wrapsubtract_arrays ../tests/drm-formats-test.c:467
#7 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#8 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#9 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#10 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#11 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#12 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#13 0x55723c680844 in main ../tests/weston-test-runner.c:661
#14 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#15 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 96 byte(s) in 3 object(s) allocated from:
#0 0x7fae74658652 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:164
#1 0x7fae74473b76 in wl_array_add (/usr/lib/libwayland-client.so.0+0xab76)
#2 0x7fae744dd142 in modifiers_subtract ../libweston/drm-formats.c:384
#3 0x7fae744dd408 in weston_drm_format_array_subtract ../libweston/drm-formats.c:431
#4 0x55723c67bed5 in subtract_arrays ../tests/drm-formats-test.c:487
#5 0x55723c67b6bb in wrapsubtract_arrays ../tests/drm-formats-test.c:467
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 64 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658652 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:164
#1 0x7fae74473b76 in wl_array_add (/usr/lib/libwayland-client.so.0+0xab76)
#2 0x7fae744dd142 in modifiers_subtract ../libweston/drm-formats.c:384
#3 0x7fae744dd408 in weston_drm_format_array_subtract ../libweston/drm-formats.c:431
#4 0x55723c67d8d5 in subtract_arrays_exclusive_modifiers ../tests/drm-formats-test.c:584
#5 0x55723c67d31d in wrapsubtract_arrays_exclusive_modifiers ../tests/drm-formats-test.c:561
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658279 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fae74473bc3 in wl_array_add (/usr/lib/libwayland-client.so.0+0xabc3)
#2 0x7fae744dc19f in weston_drm_format_array_add_format ../libweston/drm-formats.c:166
#3 0x7fae744dd3de in weston_drm_format_array_subtract ../libweston/drm-formats.c:426
#4 0x55723c67d8d5 in subtract_arrays_exclusive_modifiers ../tests/drm-formats-test.c:584
#5 0x55723c67d31d in wrapsubtract_arrays_exclusive_modifiers ../tests/drm-formats-test.c:561
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658279 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fae74473bc3 in wl_array_add (/usr/lib/libwayland-client.so.0+0xabc3)
#2 0x7fae744dc19f in weston_drm_format_array_add_format ../libweston/drm-formats.c:166
#3 0x7fae744dd3de in weston_drm_format_array_subtract ../libweston/drm-formats.c:426
#4 0x55723c67deca in subtract_arrays_modifier_invalid ../tests/drm-formats-test.c:613
#5 0x55723c67da3d in wrapsubtract_arrays_modifier_invalid ../tests/drm-formats-test.c:593
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658279 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fae74473bc3 in wl_array_add (/usr/lib/libwayland-client.so.0+0xabc3)
#2 0x7fae744dc19f in weston_drm_format_array_add_format ../libweston/drm-formats.c:166
#3 0x7fae744dd3de in weston_drm_format_array_subtract ../libweston/drm-formats.c:426
#4 0x55723c67c9c0 in subtract_arrays_same_content ../tests/drm-formats-test.c:521
#5 0x55723c67c55b in wrapsubtract_arrays_same_content ../tests/drm-formats-test.c:504
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
The DRM backend uses changes in the cursor view memory address and
surface damage to detect when it needs to re-upload to a cursor plane
framebuffer.
However, when a cursor view is destroyed and then recreated, e.g., when
the pointer cursor surface is updated, the newly created view may have
the same memory address as the just destroyed one. If no new cursor
buffer is provided (because it was attached, committed and used
previously) when this address reuse occurs, then there also isn't any
updated surface damage and the backend doesn't update the cursor plane
framebuffer at all.
To fix this issue utilize the destroy signal to track when the cursor
view is destroyed, and clear the cached cursor_view value in drm_output.
After clearing the cached value, the next cursor view is always
considered new and thus uploaded to the plane properly.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
This creates the FP16 shadow framebuffer automatically if the color
transformation from blending space to output space is not identity and
the backend does not claim to implement it on the renderer's behalf.
That makes the weston_output_set_renderer_shadow_buffer() API and
use-renderer-shadow weston.ini option obsolete.
To still cater for the one test that needs to enable the shadow
framebuffer in spite of not needing it for color correct blending, the
quirk it uses now also forces the shadow.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Compile time constants play an important role in keeping the shader
programs fast. Introduce an informal annotation to mark compile time
constants to make the shader code easier to reason with.
This will make much more sense once functions with compile time constant
parameters are added.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Trying to support GL ES 2.0 + extensions along with GL ES 3.0 for better
control is becoming too complicated fast. In this patch you see the
GL_RGBA vs. GL_RBA16F and GL_HALF_FLOAT vs. GL_HALF_FLOAT_OES paths.
More such cases will come, e.g. GL_RED_EXT vs. GL_R32F.
Make things simpler and require GL ES 3.0 +
GL_EXT_color_buffer_half_float for all color management related
functionality. If one doesn't have GL ES 3.0, all you lose is color
management.
Also, all extensions needed by color transformation operations are
gathered under one boolean flag instead of having a flag per extension,
again for simplicity.
This makes the GL ES extension handling much easier.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This reverts commit 36d699a164.
A different way to fix this same issue is the previous commit
"gl-renderer: do not unbind the context on output destroy"
which is needed for other reasons.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
If we make EGL_NO_CONTEXT current, all following GL calls are
no-ops. This will be a problem when gl-renderer introduces
gl_renderer_color_transform containing GL textures and needs to destroy
them when weston_color_transform is destroyed. Mesa would print the the
warning that glDeleteTextures is no-op.
To fix this, keep our GL context current when destroying a GL output.
In case EGL_KHR_surfaceless_context is not available, we must use
dummy_surface.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This creates the color-lcms plugin that in the future will be using
Little CMS as the color matching module, processing ICC profiles, and
producing HDR tone mappings.
Right now, this new plugin is functionally equivalent to the no-op color
manager, except it already links to lcms2 and checks that the renderer
supports color operations.
Color-lcms is a libweston plugin that is loaded with explicit
weston_compositor API. This does not currently allow loading alternative
color manager plugins. External color manager plugins might be
considered in the future when the libweston APIs around color management
stabilize.
This libweston plugin uses the same build option as the old cms-static
Weston plugins, as they both need lcms2. The minimum version for lcms2
was chosen by what Debian Buster provides today and for no other reason.
This plugin intends to support the Wayland CM&HDR protocol extension and
hence sets supports_client_protocol to true. This will expose the
protocol extension to clients when it gets implemented.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is needed when the compositor produces any content internally:
- the lines in triangle fan debug
- the censoring color fill (unmet HDCP requirements)
Solid color surfaces do not need this special-casing because
weston_surface is supposed to carry color space information, which will
get used in gl_shader_config_init_for_view().
This makes sure the internally produced graphics fit in, e.g on a
monitor in HDR mode.
For now, just ensure there is an identity transformation. Actual
implementations in GL-renderer will follow later.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is needed when drawing anything internal directly to an output,
like the borders/decorations in a nested compositor setup. This makes
the assumption that the internal stuff starts in sRGB, which should be
safe. As borders are never blended with other content, this should also
be sufficient.
This patch is a reminder that that path exists, rather than a real
implementation. To be implemented when someone needs it.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is the blending space to monitor space color transform. It needs to
be implemented in the renderers, unless a backend sets
from_blend_to_output_by_backend = true, in which case the backend does
it and the renderer does not.
The intention is that from_blend_to_output_by_backend can be toggled
frame by frame to allow backends to react to dynamic change of output
color profile.
For now, renderers just assert that they don't need to do anything for
output color transform.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
See: https://gitlab.freedesktop.org/wayland/weston/-/issues/467#note_814985
This starts building the framework required for implementing color
management.
The main new interface is struct weston_color_manager. This commit also
adds a no-op color manager implementation, which is used if no other
color manager is loaded. This no-op color manager simply provides
identity color transforms for everything, so that Weston keeps running
exactly like before.
weston_color_manager interface is incomplete and will be extended later.
Colorspace objects are not introduced in this commit. However, when
client content colorspace and output colorspace definitions are
combined, they will produce color transformations from client content to
output blending space and from output blending space to output space.
This commit introduces a placeholder struct for color transforms,
weston_color_transform. Objects of this type are expected to be heavy to
create and store, which is why they are designed to be shared as much as
possible, ideally making their instances unique. As color transform
description is intended to be generic in libweston core, renderers and
backends are expected to derive their own state for each transform
object as necessary. Creating and storing the derived state maybe be
expensive as well, more the reason to re-use these objects as much as
possible. E.g. GL-renderer might upload a 3D LUT into a texture and keep
the texture around. DRM-backend might create a KMS blob for a LUT and
keep that around.
As a color transform depends on both the surface and the output, a
transform object may need to be created for each unique pair of them.
Therefore color transforms are referenced from weston_paint_node. As
paint nodes exist for not just surface+output but surface+view+output
triplets, the code ensures that all paint nodes (having different view)
for the same surface+output have the same color transform state.
As a special case, if weston_color_transform is NULL, it means identity
transform. This short-circuits some checks and memory allocations, but
it does mean we use a separate member on weston_paint_node to know if
the color transform has been initialized or not.
Color transformations are pre-created at the weston_output
paint_node_z_order_list creation step. Currently the z order lists
contain all views globally, which means we populate color transforms we
may never need, e.g. a view is never shown on a particular output.
This problem should get fixed naturally when z order lists are
constructed "pruned" in the future: to contain only those paint nodes
that actually contribute to the output's image.
As nothing actually supports color transforms yet, both renderers and
the DRM-backend assert that they only get identity transforms. This
check has the side-effect that all surface-output pairs actually get a
weston_surface_color_transform_ref even though it points to NULL
weston_color_transform.
This design is inspired by Sebastian Wick's Weston color management
work.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
A following patch will need the paint node in
gl_shader_config_init_for_view() for color transformations.
While passing the paint node through, rename the functions to be more
appropriate and get surface/view/output from the paint node.
This is a pure refactoring with no functional change.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
A following patch will need the paint node in draw_view() for color
transformations.
While passing the paint node into draw_paint_node, also use the paint
node. This is a pure refactoring with no functional change.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
When setting a cursor surface, use the surface dimensions, instead of the
weston_surface buffer reference, to check if the surface has any
content. A weston_surface without any buffer reference may in fact
have a buffer which was committed in a previous pointer entry, dropped
by weston_surface and now held only internally by the renderer.
Without this fix, when a pointer enters a surface, the cursor image is
not correctly updated if we set a cursor surface with an already
committed buffer from a previous pointer entry, without recommitting the
cursor buffer for the current entry. This can be seen, for example, in
the experimental Wine Wayland driver which handles the cursor in a way
that leads to the following scenario:
Setup: cursor_surface.attach(buffer) & cursor_surface.commit()
On first wl_pointer.enter: pointer.set_cursor(cursor_surface)
compositor/renderer redraws
wl_pointer.leave
On second wl_pointer.enter: pointer.set_cursor(cursor_surface)
When handling the second pointer.set_cursor() request the current code
doesn't find a buffer attached to the cursor_surface (only the renderer
now has a reference to it), so it doesn't update the respective view for
the cursor.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Remove all the backend code to support drivers without universal planes.
From[1]:
"The code needed to support kernels where DRM does not support uiniversal
planes makes the DRM-backend a little more complicated, because it needs
to create fake planes for primary and cursor. The lifetimes of the fake
planes does not match the lifetime of "proper" planes, which is surprising."
And since the universal planes left the experimetal flag in 2014[2] it is
safe to remove the support now.
[1] https://gitlab.freedesktop.org/wayland/weston/-/issues/427
[2] https://cgit.freedesktop.org/drm/drm-tip/commit/?id=c7dbc6c9ae5c3baa3be755a228a349374d043b5b
Signed-off-by: Igor Matheus Andrade Torrente <igormtorrente@gmail.com>
Fix an issue where the keyboard leds will go out of sync when a new
keyboard is connected.
The issue can be easily reproduced by connecting two keyboards, enabling
caps lock, and reconnecting one of the keyboards. Without the patch the
leds on both keyboards will turn off while the actual caps lock state
will stay enabled.
Signed-off-by: Samu Nuutamo <samu.nuutamo@gmail.com>
Fixes a definitely lost:
== 56 bytes in 1 blocks are definitely lost in loss record 16 of 45
== at 0x48450F8: malloc (vg_replace_malloc.c:309)
== by 0x4B55E93: wl_event_loop_add_timer (event-loop.c:197)
== by 0x4126CF: weston_compositor_create (in /usr/local/bin/weston)
== by 0x409997: main (in /usr/local/bin/weston)
Signed-off-by: Lujin Wang <luwang@nvidia.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Layers did not have a fini sequence before, which means the compositor
layer list might have stale pointers temporarily when shutting down. A
bigger problem might be having views linger after the destruction of the
layer.
These problems were not observed yet, but if they exist, this patch
should help to find them and then fix them.
The check in weston_compositor_shutdown() is not an assert yet, because
it will trigger until all components call weston_layer_fini() correctly.
Some components do not even have a tear-down function to call it from at
all, like fullscreen-shell.
The same with the check in weston_layer_fini().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
These are all the remaining places that still use the global view_list,
and cannot avoid it. Add a comment to explain why in each.
Now all places that use view_list have been audited for paint node
lists.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Iterate paint nodes instead of the global view list. Right now this does
not change behavior.
This is a step towards using per-output view lists that can then be
optimized for the output in libweston core.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Iterate paint nodes instead of the global view list. Right now this does
not change behavior.
This is a step towards using per-output view lists that can then be
optimized for the output in libweston core.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Iterate paint nodes instead of the global view list. Right now this does
not change behavior.
This is a step towards using per-output view lists that can then be
optimized for the output in libweston core.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Iterate paint nodes instead of the global view list. Right now this does
not change behavior.
This is a step towards using per-output view lists that can then be
optimized for the output in libweston core.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Iterate paint nodes instead of the global view list. Right now this does
not change behavior.
This is a step towards using per-output view lists that can then be
optimized for the output in libweston core.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This patch creates a per-output paint node list in the same z-order as
the global view_list in weston_compositor.
The next step is to switch output repaints and backends to use the
z-order list instead of view_list.
Having a per-output paint node list for repaints allows including only
those paint nodes that actually contribute to the output image, so that
completely occluded and out-of-screen views can be ignored in libweston
core already.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This new object is created for every surface-view-output triplet. As
there is always exactly one surface for a view and it does not change
during a view's lifetime, this is really for a view-output pair or a
surface-output pair.
The object is created on-demand as a part of preparing for an output
repaint, so it applies only to surfaces that are going through repaint.
A prerequisite for that is that the surface is mapped, which means it
has a mapped view.
When any one of surface or view gets destroyed or output gets disabled,
all related paint nodes are destroyed.
In future, paint node will be useful for caching surface-output or
view-output pair dependent data:
- damage regions for overlapping outputs
- color transformations
- backend-specific bookkeeping (e.g. DRM KMS plane assigments)
- per-output repaint lists
- surface geometry transformed into output space
Suggested by Daniel Stone in
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/582#note_899406
PS. The call in weston_view_destroy() to
weston_compositor_build_view_list() might be so that if the view has
sub-surfaces, rebuilding the view list removes those those too and
automagically deletes their views.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Use the real name of the seat instead of calling each seat 'default'. This makes
it easier to identify the current seat in a multi-seat environment.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
This change fixes the "touch-up" operation to clear "data_source"
by setting "seat" to NULL. This operation is done in the mouse button
release operation, but seems to have been forgotten in the "touch up"
case.
Forgetting this operation causes weston to send a "premature finish
request" error to the client which causes the client to exit.
This issue can be reproduced with the "weston-dnd" program by performing
a drag-and-drop operation with a touch input device. Once the drag
is released, the weston-dnd program will exit with an error.
Signed-off-by: Jonathan Marler <johnnymarler@gmail.com>
If sprites_are_broken, then we will only ever arrive in renderer_only
mode, so this case will be caught by the checks above.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Avoids an user-after-free when destroying the surface, like in the
following ASAN message:
==25180==ERROR: AddressSanitizer: heap-use-after-free on address 0x6060000589d8 at pc 0x7ff70a4f7102 bp 0x7fff8f7e13b0 sp 0x7fff8f7e13a8
READ of size 8 at 0x6060000589d8 thread T0
#0 0x7ff70a4f7101 in weston_schedule_surface_protection_update ../libweston/compositor.c:1163
#1 0x7ff70a4f743b in weston_surface_update_output_mask ../libweston/compositor.c:1212
#2 0x7ff70a4f7a47 in weston_surface_assign_output ../libweston/compositor.c:1298
#3 0x7ff70a4f7f44 in weston_view_assign_output ../libweston/compositor.c:1348
#4 0x7ff70a4fa12f in weston_view_update_transform ../libweston/compositor.c:1589
#5 0x7ff70a4ffc20 in view_list_add ../libweston/compositor.c:2657
#6 0x7ff70a5000ee in weston_compositor_build_view_list ../libweston/compositor.c:2688
#7 0x7ff70a4fd577 in weston_view_destroy ../libweston/compositor.c:2202
#8 0x7ff70a4fd7df in weston_surface_destroy ../libweston/compositor.c:2239
#9 0x7ff70a4fdbb0 in destroy_surface ../libweston/compositor.c:2285
#10 0x7ff70a4a2d3e in destroy_resource ../src/wayland-server.c:723
#11 0x7ff70a4a8940 in for_each_helper ../src/wayland-util.c:372
#12 0x7ff70a4a8e1f in wl_map_for_each ../src/wayland-util.c:385
#13 0x7ff70a4a3748 in wl_client_destroy ../src/wayland-server.c:882
#14 0x7ff6fe04e866 in shell_destroy ../desktop-shell/shell.c:5004
#15 0x7ff70a4ee923 in wl_signal_emit /home/mvlad/install-amd64/include/wayland-server-core.h:481
#16 0x7ff70a51598d in weston_compositor_destroy ../libweston/compositor.c:7903
#17 0x7ff70a903a58 in wet_main ../compositor/main.c:3493
#18 0x560de7b3b179 in main ../compositor/executable.c:33
#19 0x7ff70a73ecc9 in __libc_start_main ../csu/libc-start.c:308
#20 0x560de7b3b099 in _start (/home/mvlad/install-amd64/bin/weston+0x1099)
0x6060000589d8 is located 56 bytes inside of 64-byte region [0x6060000589a0,0x6060000589e0)
freed by thread T0 here:
#0 0x7ff70a9d3b6f in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.6+0xa9b6f)
#1 0x7ff70a5167d2 in cp_destroy_listener ../libweston/content-protection.c:193
#2 0x7ff70a4ee923 in wl_signal_emit /home/mvlad/install-amd64/include/wayland-server-core.h:481
#3 0x7ff70a51598d in weston_compositor_destroy ../libweston/compositor.c:7903
#4 0x7ff70a903a58 in wet_main ../compositor/main.c:3493
#5 0x560de7b3b179 in main ../compositor/executable.c:33
#6 0x7ff70a73ecc9 in __libc_start_main ../csu/libc-start.c:308
previously allocated by thread T0 here:
#0 0x7ff70a9d4037 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.6+0xaa037)
#1 0x7ff70a5160aa in zalloc ../include/libweston/zalloc.h:38
#2 0x7ff70a516cda in weston_compositor_enable_content_protection ../libweston/content-protection.c:329
#3 0x7ff7070247e0 in drm_backend_create ../libweston/backend-drm/drm.c:3180
#4 0x7ff707024cae in weston_backend_init ../libweston/backend-drm/drm.c:3250
#5 0x7ff70a515d02 in weston_compositor_load_backend ../libweston/compositor.c:7999
#6 0x7ff70a8fbcfb in load_drm_backend ../compositor/main.c:2614
#7 0x7ff70a900b46 in load_backend ../compositor/main.c:3103
#8 0x7ff70a902ecd in wet_main ../compositor/main.c:3380
#9 0x560de7b3b179 in main ../compositor/executable.c:33
#10 0x7ff70a73ecc9 in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: heap-use-after-free ../libweston/compositor.c:1163 in weston_schedule_surface_protection_update
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Weston internals and Wayland clients assume that output presentation
clock cannot go backwards. Therefore require unconditionally that KMS
uses the monotonic clock.
The kernel unconditionally supports DRM_CAP_TIMESTAMP_MONOTONIC. See:
commit 25e1a79874eb3821d93310c908cc0a81b47af060
Author: Arnd Bergmann <arnd@arndb.de>
Date: Wed Oct 11 17:20:13 2017 +0200
drm: vblank: remove drm_timestamp_monotonic parameter
That one removed the final possibility of DRM_CAP_TIMESTAMP_MONOTONIC
being false, by removing the module option. But even before that, all
drivers have been supporting monotonic, since
commit c61eef726a78ae77b6ce223d01ea2130f465fe5c
Author: Imre Deak <imre.deak@intel.com>
Date: Tue Oct 23 18:53:26 2012 +0000
drm: add support for monotonic vblank timestamps
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This drops the software presentation clocks that could jump backwards.
See the previous commit "libweston: assert frame times never go
backwards" for the rationale.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Adding this check was prompted by
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/609
There is no reason to allow frame times jump backwards, and apparently
we already have code that makes that assumption.
DRM KMS uses CLOCK_MONOTONIC as the vblank and page flip timestamps,
which by definition cannot go backwards. Other backends call
weston_compositor_set_presentation_clock_software().
Frame times are also reported directly to Wayland clients via
presentation-time extension, and clients too will not expect that the
timestamp could go backwards.
So make sure time can never go backwards.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
As observed in #420 (Running Weston under Weston's kiosk shell with
multiple outputs causes the scrollback to go nuts), not
being able to cope with (a correct) resize of the parent surface would
cause the client weston instance to spin forever. If dispatching
failed, just exit.
Fixes#420
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
As an in-flight resize call might cause a call to
wayland_output_destroy_shm_buffers() to go over a list of free_buffers
list. Just initialize the lists before attempting to create the parent
surface to avoid it.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
fb->format is *pixel_format_info, whereas fb->format->format is the
actual DRM/wl_shm format code we want to see here. Fix the drm_debug()
call accordingly.
Signed-off-by: Bastian Krause <bst@pengutronix.de>
In "backend-drm: simplify compile time array copy", ARRAY_COPY was
introduced to be used by the DRM-backend.
In this patch we expand its usage to other code where hardcoded arrays
are being copied.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In drm_fb_get_from_dmabuf() we have some compile time array copies, and
multiple static_assert() calls are needed (for safety). This makes the
code unpleasant to read.
Add ARRAY_COPY macro, to simplify the code.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
EGL implementations have no way to tell that implicit modifiers are not
supported. So Weston must consider that implicit modifiers are
supported. Always add DRM_FORMAT_MOD_INVALID to formats that we query
from EGL.
The implication is that clients using dmabuf extension may pick
DRM_FORMAT_MOD_INVALID to allocate their buffers, and so these buffers
will not be directly imported to KMS and placed in planes. See commit
"backend-drm: do not import dmabuf buffers with no modifiers to KMS" for
more details.
But we should not avoid advertising DRM_FORMAT_MOD_INVALID in the dmabuf
protocol just because we hope that the client don't choose it, it's not
our choice.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In commit "libweston: add struct weston_drm_format" struct
weston_drm_format and its helper functions were added to libweston.
The functions query_dmabuf_formats and query_dmabuf_modifiers are very
specific to GL-renderer and its internals. So instead of exposing them
in libweston, query and store DRM formats and modifiers internally in
GL-renderer. Also, add a vfunction to struct weston_renderer in order
to retrieve the formats.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In commit "backend-drm: do not import dmabuf buffers with no modifiers
to KMS" we've stopped to import dmabuf with no modifiers to KMS.
In this patch we document why we can still import wl_drm buffers with no
modifiers to KMS.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
We can't tell the layout of a buffer that has been allocated with no
modifiers. Although usually drivers use linear layouts to allocate in
these cases, it is not a rule. It can use a tiling layout, for instance,
under the hood.
So it is not safe to import a buffer with no modifiers to KMS, as it
can't tell the buffer layout and this may result in garbage being
displayed. In this patch we start to require explicit modifiers to
import buffers to KMS.
In most cases things just work as expected, but just because both sides
(display and render driver) usually end up using the linear layout when
modifiers are not exposed. It also works on systems where the display
and render devices are tied (desktops with Intel or AMD, for instance),
as there's only one driver and it knows the layout of the buffer (no
need to guess).
But in SoC's where the display and render device are split, things can
go wrong. It is better to lose performance and not break things. To
solve the problem, drivers should be updated to expose modifiers (even
if only DRM_FORMAT_MOD_LINEAR), as the concept of implicit modifiers is
the root of the problem.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In commit "backend-drm: add DRM_FORMAT_MOD_INVALID to modifier sets when
no modifiers are supported" we've changed the code that iterates through
the IN_FORMATS blob property. Now it adds DRM_FORMAT_MOD_INVALID for
formats exposed without modifiers.
But the thing is that there shouldn't be formats in the IN_FORMATS blob
exposed without modifiers, as the blob has been added after the
introduction of the explicit modifiers API in the kernel. For now,
there's nothing in the kernel to ensure this correct behavior. So
instead of adding DRM_FORMAT_MOD_INVALID in this case, ignore these
formats, as userspace can't do much in this case.
In the future this may be fixed by the kernel. Or maybe the following MR
in libdrm, which adds an iterator API for the IN_FORMATS blob:
https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/146
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
From now on, when we can't know the modifiers supported for a certain
format, we add DRM_FORMAT_MOD_INVALID to its modifier set.
There is some parts where nothing is being added an others where
DRM_FORMAT_MOD_LINEAR is being added, so fix them.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In create_gbm_surface() we may allocate with no modifiers in the
following situations:
1. old GBM version, so HAVE_GBM_MODIFIERS is false;
2. the KMS driver does not support modifiers;
3. if allocating with modifiers failed, what can happen when the KMS
display device supports modifiers but the GBM driver does not, e.g.
the old i915 Mesa driver.
The comment was only stating the third situation, so add the other two.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
The function drm_output_init_egl() is too big, so move the code to
create the gbm surface to a separate function: create_gbm_surface().
Also made some minor style changes to the code that has been moved, in
order to improve readability.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In commit "libweston: add struct weston_drm_format" struct
weston_drm_format and its helper functions were added to libweston.
Also, unit tests for this API have been added in commit "tests: add unit
tests for struct weston_drm_format".
Start to use this API in the DRM-backend, as it enhances the code by
avoiding repetition and ensuring correctness.
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
Co-authored-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Add struct weston_drm_format, which contains a DRM format and a list of
modifiers. The patch also adds struct weston_drm_format_array and some
helper functions to handle these two new structs: init/fini, find
elements, add elements, etc.
This will be useful in the next commits in which we add support to
dmabuf-hints. It also allows a cleanup in the DRM-backend, where we
currently have a similar struct in drm_plane but with no helper
functions, so the code to handle it is scattered throughout the
functions and there is a lot of repetition.
This patch is based on previous work of Scott Anderson (@ascent).
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In drm_output_prepare_plane_view() we iterate the list of planes and add
them as candidates to promote the view to one of them.
Cursor planes do not support buffers other than wl_shm (at least for
now). So when we have a dmabuf or an EGL buffer in the view, the
function drm_output_plane_cursor_has_valid_format() returns false and
the cursor plane is not added to the candidate list.
In this patch we move the responsibility of doing this from
drm_output_plane_cursor_has_valid_format() to
drm_output_prepare_plane_view() itself, as the incompatibility between
other types of buffers and cursor planes is different from the
incompatibility between formats. This makes the code easier to read
and also documents the current incompatibility between cursor planes
and buffers that are not created through wl_shm.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In the absence of universal planes support,
drm_output_find_special_plane() sets the plane format to zero as a
placeholder. Then in drm_output_init_planes() it sets the format to
output->gbm_format.
As output->gbm_format is already set by the time we call
drm_output_find_special_plane(), simply set the plane format to it
directly in this function. This makes the code clearer, as there is no
reason to use the placeholder.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
get_vt is used to check if VTs are enabled, by verifying that a VT greater than
0 is returned.
libseat always implements switching, with switch to an active session
currently being a noop in all backends. libseat does not currently have
a get_vt implementation. Make get_vt errors more explicit, and allow VT
switching anyway if the error is ENOSYS.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
This adds support for libseat as a seat backend. libseat provides seatd,
(e)logind and direct seat backends as compile-time and runtime options.
The backend is currently disabled by default. It can be enabled through the
launcher-libseat option.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
In some situations, like positioning a sub-surface that exceeds the
output's dimensions we would adjust the plane state dimensions to some
lower values to that of the buffer. That would ultimately trip the cursor
update function because the buffer itself actually exceeds the maximum
size/dimension of the cursor.
The plane state destination co-ordinates is the area of the view which
is visible on the output, which in some situations, would actually be
smaller than the original buffer dimensions (making it so that it will
pass the cropping/scaling check), but depending on of
how large is the surface buffer, it would tripping the assert wrt to
cursor width/height dimensions.
This hasn't been seen so far due to the fact that until recently we had
a cursor surface that always reached the cursor plane and that was
already being set-up by default (with desktop-shell, which is no longer
the case), and also because kiosk-shell, which doesn't set-up a cursor
surface, was not available.
This adds a check to skip placing the view in the cursor plane if the
buffer dimensions exceed the cursor permitted width/height.
(Suggested-by Daniel Stone).
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
fixes issue #484 (race condition with message to/from weston launch)
The race condition occurs after weston sends the WESTON_LAUNCHER_OPEN
message to weston-launch. The race is between when weston-launch replies
with the fd handle versus weston-launch sending an activation message. If
weston-launch sends an activation message before sending the fd handle,
then weston will be in an invalid state.
To fix this, I modified the fd handle reply that weston-launch sends to
include a message id at the beginning, which I called
WESTON_LAUNCHER_OPEN_REPLY. Along with this, weston now inspects the
first part of any reply to determine whether it is an activation message
or a reply to the OPEN message. In the newly handled case that it's an
activation message, it tracks whether the latest result is a deactivate
message and stores it in a flag to be handled once the open function has
completed.
Signed-off-by: Jonathan Marler <johnnymarler@gmail.com>
Now that pieces of color management implementation start to land, the
fallback shader becomes even more special than before. It is the only
case where the compositor ignores color management.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The texture target can be uniquely inferred from the shader variant, so
do not store texture target separately.
Shortens the code a bit.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Replace the shader_requirements with just shader_variant. The variant is
the only thing gl_surface_state will actually carry. All the other
requirements fields are always unused.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This patch gathers all values to be loaded to shader uniforms into a new
struct gl_shader_config along with texture target and filter
information. Struct gl_shader becomes opaque outside of gl-shaders.c.
Everything that used or open-coded these are converted.
The aim is to make gl-renderer.c easier to read. Previously, uniform
values were loaded up in various places, texture units were set up in
one place, textures were bound into units in different places. Stuff was
all over the place.
Now, shader requirements and associated uniform data is stored in a
single struct. The data is loaded into a shader program in one function
only.
That makes it easy for things like maybe_censor_override() to replace
the whole config rather than poke only the shader requirements. This may
not look like much right now, but when color management adds more
uniforms and even hardcoded color need to go through the proper color
pipeline, doing things the old way would become intractable.
Similar simplification can be seen in draw_view(), where the RGBA->RGBX
override becomes more contained. There is no longer a need to "pre-load"
the shader used by triangle fan debug. Triangle fan debug no longer
needs to play tricks with saving and restoring the current shader.
The real benefit of this change will probably come when almost all
shader operations need to take color spaces into account. That means
filling in gl_shader_config parts based on a color transformation.
This is based on an idea Sebastian already used in his Weston color
management work.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Avoid looking up 'gr' from view->compositor by passing it explicitly
into the functions needing it.
Also fixes the whitespace in repaint_region() signature.
Clarifies code by removing local variables, but also future changes will
need 'gr' more.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
A future change will call this function from draw_view(), so move it
upwards to avoid adding a function declaration.
No functional or even cosmetic change.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
These functions are related to shaders, so they are more at home in
gl-shaders.c. gl-renderer.c is too long already.
This allows making a couple functions static while the moved functions
become non-static. Future changes turn some of these functions into
static again, with the ultimate goal of making struct gl_shader opaque.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Tearing down the drm-backend when there are no input devices, would call
for the gbm device destruction before compositor shutdown. The latter
would call into the renderer detroy function and assume that the
EGLDisplay, which was created using the before-mentioned gbm device, is
still available. This patch re-orders the gbm destruction after the
compositor shutdown when no one would make use of it.
Fixes: #314
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
Everywhere else uses #ifdef, this used just #if. When the next commit
adds -Wundef to the compiler options, this #if here will start failing
as ENABLE_EGL is undefined.
It would be much better to use Meson's set10() for ENABLE_EGL and change
all #ifdef into #if, but I opted for the smaller change for now.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
