Make it obvious that weston_surface has a reference counting happening
and destruction of the weston_surface happens when the last
weston_surface reference has been accounted for.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Unconditionally creating a surface feedback for each surface
creates unnecessary overhead and noise in the logs. Thus
create it when the first surface feedback resource for a
surface is requested and delete it again once all those
resources have been destroyed.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
I am going to need to add yet another output property to be set by a
color manager: HDR Static Metadata Type 1. With the old color manager
API design, I would have needed to add the fourth function pointer to be
called always in the same group as the previous three. This seemed more
convoluted than it needs to be.
Therefore collapse the three existing function pointers in the API into
just one that is resposible for setting up all three things.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This new struct collects all the things that a color manager needs to
set up when any colorimetry aspect of an output changes. The intention
is to make the color manager API less verbose.
In this first step, the new struct is added and replaces the fields in
weston_output.
The intention is for the following color manager API changes to
dynamically allocate this structure. Unfortunately, until that actually
happens, we need a temporary way to allocate it. That is
weston_output::colorout_, which will be removed in the next patch. This
keeps the patches more palatable for review at the cost of some
back-and-forth in code changes.
This is a pure refactoring, no functional changes.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is the switch to turn HDR mode on.
The values in the enumeration come straight from CTA-861-G standard.
Monitors advertise support for some of the HDR modes in their EDID, and
I am not aware of any other way to detect if a HDR mode actually works
or not. Different monitors may support different and multiple modes.
Different modes may look different. Therefore the high-level choice of
how to drive a HDR video sink is left for the Weston frontend to decide.
All the details like what HDR metadata to use are left for the color
manager.
This commit adds the libweston API for backends to advertise support and
for frontends to choose a mode. Backend and frontend implementations
follow in other commits.
The frontend API does not limit the EOTF mode to the supported ones to
allow experimentation and overriding EDID.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Rather than punching through to set the surface as a solid colour,
attach an actual weston_buffer to it instead.
This becomes the first user of attaching non-client-generated buffers
to a weston_surface. As a result, it is necessary to introduce a
function which will allow compositors and shells to attach a buffer to a
surface. weston_surface_attach_solid() is therefore introduced as a
special-purpose helper which will attach a solid buffer to a
weston_surface.
It is not intended as a general-purpose mechanism to allow compositors
to attach client-generated buffers to surfaces, as doing so would have
unknown effects on this core part of the compositor itself.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Currently solid-colour displays (e.g. the background for fullscreen
views) is implemented by a special-case weston_surface which has no
buffer attached, with a special punch-through renderer callback to set
the colour.
Replace this with a weston_buffer type explicitly specifying the solid
colour, which helps us eliminate yet more special cases in renderers and
backends.
This is not handled yet in any renderer or backend, however it is also
not used by anything yet. Following commits add support to the renderers
and backends.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When the renderer/backend indicate that they do not need a surface's
buffer content to be preserved, most often because they have copied it,
simply downgrade the buffer reference to 'will not access', rather than
drop the buffer reference altogether.
Signed-off-by: Daniel Stone <daniels@collabora.com>
In the original conception, a weston_buffer_reference indicated that the
underlying contents of the wl_buffer would or could be accessed, so
wl_buffer.release must not be sent until the last reference was
released, as the compositor may still use it.
This meant that renderers or backends which copied the buffer content -
such as the GL renderer with SHM buffers - could only send a buffer
release event to the client by 'losing' the buffer reference altogether.
The main side effect is that `weston-debug scene-graph` could not show
any information at all about SHM buffers when using the GL renderer, but
it also meant that renderers and backends grew increasingly exotic
structures to cache information about the buffer.
Now that we have an additional buffer-reference mode (still referring to
the weston_buffer/wl_buffer, but not going to access its content), we
can allow the weston_buffer_reference and weston_buffer to live as long
as the buffer itself, even if we do send a release event.
This will enable a bunch of backend and renderer deduplication, as well
as finally making scene-graph more useful.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Add a mode argument to weston_buffer_reference which indicates whether a
buffer's storage may/will be accessed, or whether the underlying storage
will no longer be accessed, e.g. because it has been copied. This will
be used to retain a pointer to the weston_buffer whilst being able to
send a release event to the client.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Keep the weston_buffer alive for as long as at least one of the
underlying wl_buffer or a backend usage exists.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We currently allow a weston_buffer to outlive the underlying wl_buffer
iff the renderer/backend has cached it. Currently the 'is this buffer
valid?' test relies on looking for the validity of the weston_buffer
itself; shift these tests to looking at the validity of the underlying
resource.
Signed-off-by: Daniel Stone <daniels@collabora.com>
y_inverted meant that the buffer's origin was (0,0), and non-inverted
meant that the buffer's origin was (0,height). In practice, every buffer
was 'inverted' into our natural co-ordinate space that we use
everywhere.
Switch to using an explicit origin enum to make this more clear.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Rather than calling accessors (wl_shm_buffer_get etc) to figure out
which type our buffer is, just look in the structure.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Rather than open-coding various resource -> type accessors, just stick a
type enum in the buffer struct.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Rather than only filling weston_buffer information when we first come to
use it, add an explicit hook so we can fill the dimensions the first
time the buffer's attached.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When we first see a buffer attached, we create a weston_buffer for it.
The weston_buffer doesn't contain any useful information in and of
itself; that's left to renderers to populate later.
Switch this to doing it in the core at the first opportunity, at least
for SHM and dmabuf buffers; EGL buffers will follow in the next commit.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We already have the buffer in the caller, and every no-op implementation
will want to access the buffer. So might as well pass it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Seems that we're still missing layer clean-ups, with the touch
calibrator being one of them. Call the appropriate function when
shutting down the compositor instance.
Fixes: #603
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
The repaint_data is entirely backend specific. Moreover, it is only used by the
drm backend, while other backends ignore the repaint data.
There will always be only one repaint active, thus, there is no need to pass the
repaint data from the outside.
The repaint_data breaks with the multi-backend series, which calls repaint begin
for all backends to get the repaint_data. The repaint_data of the last backend
will then be passed to all other backend. At the moment, this works, because the
drm backend is the only backend that implements the begin_repaint call.
Another option would be to track the repaint data per backend in the compositor,
but actually, it the backend needs to track state across the calls, it's its own
responsibility.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Fbdev backend was deprecated in the Weston 10.0.0 release with
6338dbd581. Before that, I suggested
already in 2019 to remove it, but it was too soon then. Now it seems the
final voices asking for fbdev to be kept have been satisfied, see the
linked issue.
Fbdev-backend uses a kernel graphics UAPI (fbdev) which is sub-par for a
Wayland compositor: you cannot do GPU accelerated graphics in any
reasonable way, no hotplug support, multi-output support is tedious, and
so on. Most importantly, Linux has deprecated fbdev a long time ago due
to the UAPI fitting modern systems and use cases very poorly, but cannot
get rid of it if any users remain. Let's do here what we can to reduce
fbdev usage.
I am doing color management related additions to libweston which require
adding checks to every backend. One backend less is less churn to write
and review.
Libweston major version has already been bumped to 11, so the next
release will be Weston 11, without fbdev. enum weston_compositor_backend
entries change their numerical values.
Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/581
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The built-in backend of libseat requires users to enable a logging
level in order for libseat to start writing out log messages. For that
to happen we split out the info and error log level messages into the
compositor's log scope, while debug level messages go into a dedicated
scope.
With that, this patch brings in a new scope, called libseat-debug, which
users need to explicity create a subscription for it as to retrieve/have
access to debug message coming out of libseat. Note that by default we
have a subscription for the log-scope so any errors/info from libseat
would be displayed to the user.
Signed-off-by: Marius Vlad <marius.vlad@collabora.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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
This adds a heuristic for freeing shader programs that have not been
needed for a while. The intention is to stop Weston accumulating shader
programs indefinitely, especially in the future when color management
will explode the number of possible different shader programs.
Shader programs that have not been used in the past minute are freed,
except always keep the ten most recently used shader programs anyway.
The former rule is to ensure we keep shader programs that are actively
used regardless of how many. The latter rule is to prevent freeing too
many shader programs after Weston has been idle for a long time and then
repaints just a small area. Many of the shader programs could still be
relevant even though not needed in the first repaint after idle.
The numbers ten and one minute in the above are arbitrary and not based
on anything.
These heuristics are simpler to implement than e.g. views taking
references on shader programs. Expiry by time allows shader programs to
survive a while even after their last user is gone, with the hope of
being re-used soon. Tracking actual use instead of references also
adapts to what is actually visible rather than what merely exists.
Keeping the shader list in most recently used order might also make
gl_renderer_get_program() more efficient on average.
last_repaint_start time is used for shader timestamp to avoid calling
clock_gettime() more often. Adding that variable is an ABI break, but
libweston major has already been bumped to 10 since last release.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Converting a region from global coordinates to output pixel coordinates
will become useful in GL-renderer soon, so move this function to be
shared. It is tricky to reinvent.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This adds the libweston capability bit for "color operations" which
refers to a renderer's support for operations needed for color
management. GL-renderer will grow the support while Pixman-renderer will
not, which is why the cap is needed.
To make an example use of the cap, this also adds new API:
weston_output_set_renderer_shadow_buffer(). This is a temporary API to
enable future experimental features. The first such feature will be the
renderer internal shadow buffer, the boolean variable for it taken from
Harish Krupo's "weston.ini: introduce use-shadow-fbo in output config".
Obviously this patch does not implement the renderer shadow buffer. No
renderer sets WESTON_CAP_COLOR_OPS yet so trying to enable it will fail.
The documentation here is deliberately vague, because the bits needed
for color management will come in trickling for a long time until we can
call it color management in any sense. Until then, the temporary API
shall remain, perhaps poorly named.
Cc: Harish Krupo <harishkrupo@gmail.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Until now we had the test quirks initialization in wet_main(),
just after calling weston_compositor_create(). But there are
some cases that require the quirks during struct weston_compositor
creation time.
Move test quirks initialization to weston_compositor_create()
in order to cover more use cases for the test quirks mechanism.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Until now we had struct wet_testsuite_data as an opaque
struct that should be defined by the testsuite of libweston
users. Instead, keep the data as a void * and document that
users are responsible for defining the data type.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
There are some specific cases in which we need Weston to
behave differently when running in the test suite. This
adds a new API to allow the tests to select these behaviors.
For instance, in the DRM backend we plan to add a writeback
connector screenshooter. In case it fails for some
reason, it should fallback to the renderer screenshooter
that all other backends use. But if we add a test to
ensure the correctness of the writeback screenshooter,
we don't want it to fallback to the renderer one, we
want it to fail. With this new API we can choose to
disable the fallback behavior specifically for this test.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
The opaque region is used to determine where the views underneath the current
view must be drawn. If the opaque is not clipped, then the area that is part of
the opaque region but not part of the scissor area is not drawn at all.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Subsurfaces inherit the scissor region from the parent surface. Currently
the region is updated at the end of weston_view_update_transform(). As a
result, the old region is used to clip the transform.boundingbox of the
subsurface.
Change the order to update the scissor region after the transform.matrix is
updated but before it is used.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
As from commit b7e5f10bf4, weston_view_is_opaque() is called from
debug_scene_graph_cb(), which on its own represents a (different)
scope. By default, we already have a subscriber for the 'log' scope,
which will cause a harmless, yet spurious, message.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
compositor_accumulate_damage() is called for each output during repaint.
The DRM backend will only set keep_buffer for the surfaces that are visible on
the current output. So a buffer_ref is released that may still be needed. When
the output that shows the surface is repainted, the buffer_ref is gone and the
surface cannot be put on a plane.
Ignore all surfaces that are not visible on the current output to avoid this.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Currently the debug output for 'drm-backend' can be confusing. In the output of
debug_scene_view_print() views may be listed as 'not opaque' but later, during
plane assignment, other views underneath such a view is reported as 'occluded on
our output'.
This happens because weston_view_is_opaque() has some extra checks to determine
if a view is fully opaque, such as 'is_opaque' provided by the renderer for
formats that have no alpha channel.
Use weston_view_is_opaque() in debug_scene_view_print() as well to get more
accurate results.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
All timeline event timestamps are in CLOCK_MONOTONIC already. DRM KMS
timestamps are practically guaranteed to be CLOCK_MONOTONIC too, even though
presentation clock could theoretically be something else. For other backends,
the presentation clock is likely CLOCK_MONOTONIC_RAW due to
weston_compositor_set_presentation_clock_software().
This patch ensures that the recorded vblank timestamp is in CLOCK_MONOTONIC.
Otherwise interpreting the timeline traces might be difficult to do accurately,
since it would be hard to recover the relationship between the presentation
clock and timeline event timestamps.
The time conversion routine is the simplest possible, I don't think we need any
more accurate conversion for timeline purposes. Besides, DRM-backend is the
only backend where the timings actually matter, the other backends are
software-timed anyway.
Since the clock domain of the "vblank" attribute potentially changes, the
attribute is renamed. Wesgr never used this attribute.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
If a surface has subsurfaces then the surface itself is in the subsurface
list. To avoid printing it again there is a check to skip the child view,
if it is the same as the current view.
However, this fails when a surface with subsurfaces has two (or more) views:
The check to skip the parent fails for the other view and the two views are
printed again and again until a stack overflow occurs.
So instead check if the parent view of the subsurface view is the current
view. This way, any view that does not belong to a real subsurface is
skipped.
As a side effect, this ensures that each view of the subsurfaces is only
printed once at the correct place in the hierarchy.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Like physical size, subpixel arrangement, etc, transform advises of a
physical transform of a head, if present.
This commit adds the transform member and setter to weston_head, however
it is currently unused.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
[daniels: Extracted from one of Lucas's patches.]
Signed-off-by: Daniel Stone <daniels@collabora.com>
It was discovered in issue #99 that the implementations of the 90 and 270
degree rotations were actually the inverse of what the Wayland specification
spelled out. This patch fixes the libweston implementation to follow the
specification.
As a result, the behaviour of the the weston.ini transform key also changes. To
force all users to re-think their configuration, the transform key values are
also changed. Since Weston and libweston change their behaviour, the handling
of clients' buffer transform changes too.
All the functions had their 90/270 cases simply swapped, probably due to
confusion of whether WL_OUTPUT_TRANSFORM_* refers to rotating the monitor or
the content.
Hint: a key to understanding weston_matrix_rotate_xy(m, c, s) is that the
rotation matrix is formed as
c -s
s c
that is, it's column-major. This fooled me at first.
Fixing window.c fixes weston-terminal and weston-transformed.
In simple-damage, window_get_transformed_ball() is fixed to follow the proper
transform definitions, but the fix to the viewport path in redraw() is purely
mechanical. The viewport path looks broken to me in the presence of any
transform, but it is not this patch's job to fix it.
Screen-share fix just repeats the general code fix pattern, I did not even try
to understand that bit.
https://gitlab.freedesktop.org/wayland/weston/issues/99
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Clarifies which direction the transformation happens. All exported function
need documentation.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The only reason why we have both weston_compositor_tear_down() and
weston_compositor_destroy() is that the only we had to destroy
the log context was keeping weston_compositor alive and calling
weston_log_ctx_compositor_destroy().
After commit "weston-log: replace weston_log_ctx_compositor_destroy()
by weston_log_ctx_destroy()", it's not necessary to keep a zombie
weston_compositor just to be able to call
weston_log_ctx_compositor_destroy().
Fold weston_compositor_tear_down() into weston_compositor_destroy(),
as this split is useless now.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
The function weston_log_ctx_compositor_setup() is being called only inside
weston_compositor_create() and it is so tiny that the code gets easier to
follow if it gets folded in weston_compositor_create().
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Commit "weston-log: add function to avoid direct
access to compositor members in non-core code" added the
function weston_compositor_add_log_scope mainly to allow
libweston users to avoid direct accessing core structs, as
weston_compositor.
Replace weston_log_context_add_log_scope usage by
weston_compositor_add_log_scope.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
weston_environment_get_fd was declared in weston-launch and implemented
in compositor.c. Since the function is not used elsewhere in the code,
it is replaced by a static function in launcher-weston-launch.c
Signed-off-by: Guillaume Champagne <champagne.guillaume.c@gmail.com>
There's a function named weston_compositor_log_scope_destroy()
but it doesn't take a struct weston_compositor argument.
Rename it to weston_log_scope_destroy(), as the argument is a
struct weston_log_scope.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
There's a function named weston_compositor_add_log_scope()
but it doesn't take a struct weston_compositor argument.
Rename it to weston_log_ctx_add_log_scope(), as
the log_scope is being added to a log_context.
Also, bump libweston_major to 9.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
The member previous_damage from struct weston_output is no longer necessary.
First, stop calling init, fini and copying output_damage to it. Then remove
it from struct weston_output.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
The emission of frame_signal has to happen before a flip, otherwise
glReadPixels() could read an old frame or even worse an uninitialized buffer.
So move frame_signal emission back to renderers.
This reverts commit 2619bfe420.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
This will make possible to users that are listening to frame_signal to get
previous_damage from the data parameter instead of using
output->previous_damage.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
In order to remove duplication and make the code easier to follow, move
frame_signal emission from renderers to weston_output_repaint(). This should
have no observable effect.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
This is necessary for the test harness to be able to execute the compositor
multiple times in the same process. As we never unload opened modules, the
first compositor iteration will leave them all loaded and following compositor
iterations will then have them already loaded.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This introduces a new convention of checking through the compositor destroy
listener if the plugin is already initialized. If the plugin is already
initialized, then the plugin entry function succeeds as a no-op. This makes it
safe to load the same plugin multiple times in a running compositor.
Currently module loading functions return failure if a plugin is already
loaded, but that will change in the future. Therefore we need this other method
of ensuring we do not double-initialize a plugin which would lead to list
corruptions the very least.
All plugins are converted to use the new helper, except:
- those that do not have a destroy listener already, and
- hmi-controller which does the same open-coded as the common code pattern
did not fit there.
Plugins should always have a compositor destroy listener registered since they
very least allocate a struct to hold their data. Hence omissions are
highlighted in code.
Backends do not need this because weston_compositor_load_backend() already
protects against double-init. GL-renderer does not export a standard module
init function so cannot be initialized the usual way and therefore is not
vulnerable to double-init.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Adds a new callback 'can_scanout_dmabuf' in weston_backend, which
can be set by the back-end do determine if the buffer supplied can be
imported directly by KMS.
This patch adds a wrapper over it, 'weston_compositor_dmabuf_can_scanout'
which is called before importing the dmabuf in the GPU if the
direct_display dmabuf is being set. If that's true and the check
failed, we refuse to create a wl_buffer.
This patch avoids importing in the GPU.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Due to an error in driving GitLab, this commit erroneously contained the
entirety of !267 (zpos support in the KMS backend) squashed into one
single commit, pushed into master.
In order to keep the history clean, this is being reverted; a rebased
version of !267 with the clear individual commits which were already
present will be applied in its place.
This reverts commit 95e3b0deae.
timeline subscription
When subscribing over the command line to the 'timeline' scope we hit
the situation where we could emit a timeline message but without the
weston_output object being (fully) enabled. The timeline subscription
object requires to install its own callback on the 'destroy_signal' but
at that time, the 'destroy_signal' is not initialized.
This moves 'destroy_signal' initialization before timeline has a chance
to emit a timeline subscription message for that weston_output.
While at it, move also 'frame_signal' initialization before any function
call to keep them nicely organized.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
We notify the timeline of the fact that the object suffered
modifications through the 'set_label' function. Remove the old
refresh variable.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
With the timeline scope being created it is time to convert TL_POINT()
to use the timeline scope through the compositor instance.
This patch removes the global variable allowing to run the new timeline
code.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
With it this removes the parts responsible for creating the file,
timeline_log class, removes the debug key binding when creating the
compositor instace, keeping only what can be re-used.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
As 'new_subscription' can create additional objects, 'destroy_subscription'
will be needed when cleaning up.
As this requires a libweston_major bump (noticed by @pq), bump it up to
8.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
Commit 284d5345ad introduced a new tear_down function for the
compositor, it seems we missed a comment reference for it.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
ubsan doesn't like what we were doing here:
../libweston/compositor.c:3021:21: runtime error: signed integer overflow: -2147483648 + -1 cannot be represented in type 'int'
Rather than try to be clever in invoking weston_layer_set_mask, just build the
maximal mask explicitly.
weston_compositor_build_view_list can reconstruct the view_list without a view which was
previously in it. The existing pointers in view->link are left unchanged, which could
lead to corruption or access to released memory in wl_list_remove, depending of the
order of destruction of the views.
This can happen at least with the black view created by the desktop shell for fullscreen
surfaces, when it is hidden in lower_fullscreen_layer.
Signed-off-by: Loïc Yhuel <loic.yhuel@softathome.com>
In case of enforced protection mode, the renderer takes care of
censoring the protected content when the output recording is going on.
But in case of relaxed protection mode, the client must be notified to
avoid showing the protected content, if the output recording is on.
This patch handles the case, where the content-protection is enabled
with relaxed protection mode, and notifies the client, whenever the
recording is started or stopped.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Currently, the idle task for updating surface protection is scheduled
in case of change in the output mask of a surface or in case of change
in protection status of an output.
This patch adds a function for reusing the code to schedule the
idle-tasks, that can be called whenever there is a chance of a change
in the protection status of a surface.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
The member disable_planes of weston_output signifies the recording
status of the output, and is incremented and decremented from various
places. This patch provides helper functions to increment and decrement
the counter. These functions can then be used to do processing, before
and after the recording has started or stopped.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
We have dedicated header for the internal parts of the logging
framework, use that for the set-up part instead of the libweston public
API header.
Further more this removes weston_vlog() from public header as well and
moves them to weston-log-internal.h file.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Destroying the compositor after destroying the log scope will not print
out the messages in the tear down/clean-up phase of the compositor, so
add a new tear_down function which allows keeping a valid reference to
the compositor. This way we can destroy the compositor before destroying
the scope and keep the debug messages.
While at it remove the log context destroy part from the clean-up
of the compositor and make it stand on its own.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Rather than using 'begin_cb' rename it to a more suitable name.
Further more instead of using the scope use the subscription to pass as
an argument. The source scope is attached to the subscription when
creating it so we can access it that way.
This also adds a _complete and a _printf method for the subscription
such that the callbacks can use to write data to only _that_
subscription and to close/complete it, otherwise writing to a scope
results in writing to all subscriptions for that scope which is not
correct.
In the same time, the scope counter-parts of _write and _complete will
now use the subscription function as well.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniels@collabora.com>
Introduce a new private header file that only internal parts of the
library are allowed to use and shouldn't be exposed in the public header
of libweston.
Start by adding by adding functions that operate on the 'weston_buffer*'.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Depending on system loading, weston-launcher could drop the drm
master access before the compositor and all the clients receive
the notification. In this case, some commit could be sent to the
drm driver too late and get refused with error EACCES.
This error condition is not properly managed and causes weston to
hang.
Change the return type of start_repaint_loop() and repaint_flush()
from void to int, and return 0 on success or -1 if the repaint has
to be cancelled.
In the callers of start_repaint_loop() and repaint_flush() handle
the return value and cancel the repaint when needed.
In backend-drm detect the error EACCES and return -1.
Note: to keep the code cleaner, this change inverts the execution
order between weston_output_schedule_repaint_reset() and
repaint_cancel().
No need to wait for suspend or for any notification; in case the
weston reschedules a repaint, it will get EACCES again.
At resume, damage-all guarantees a complete repaint.
This fix is for atomic modeset only.
Legacy modeset suffers from similar problems, but it is not fixed
by this change. Since drm_pending_state_apply() never returns
error for legacy modeset, this change has no impact on legacy
modeset.
Signed-off-by: Antonio Borneo <antonio.borneo@st.com>
Fixes: https://gitlab.freedesktop.org/wayland/weston/issues/117
This patch enables a user to opt for HDCP per output, by writing into
the output section of weston.ini configuration file. HDCP is always
enabled by default for the outputs.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
The change in an output's content-protection may trigger a change in
the surface's content-protection status, and inturn the
content-protection available for the client.
This patch recomputes the content-protection level for a surface,
in case there is a change in content-protection level of an output,
showing the surface. In case of a change in the surface's
content-protection, the client associated with that surface is
notified.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
This patch adds the content-protection protocol implementation, to
enable a weston client application to request for content-protection
for its content via HDCP.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
The protection requested for a given surface, must reach through the
weston_surface::pending_state, in the commit-cycle for the
weston_surface, so that it gets updated in the next commit.
As some protection is requested for a given weston_surface, it means
protection must be set for each of the outputs which show the surface.
While setting the protection of a weston_output, care must be taken
so as to avoid, degrading the protection of another surfaces, enjoying
the protection. For this purpose, all the weston_surfaces that are
shown on a weston_output are checked for their desired protection.
The highest of all such desired protections must be set for the
weston_output to avoid degrading of existing protected surfaces.
A surface requesting protection for a lower content-type can still be
provided protection for a higher type but the converse cannot be
allowed.
This patch adds support to set content-protection for a suface, which
inturn sets the content-protection for each of the outputs on which
it is shown, provided, none of the existing surface's protection
request is downgraded.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
The actual protection status for a given weston_head depends upon the
corresponding drm_head's connector HDCP properties. On the other hand,
the actual protection for a weston_output is the minimum of the
protection status of its attached heads.
As a head's protection changes, the current protection of the output
to which the head is attached is recomputed.
This patch adds the support to keep track of the current
content-protection for heads and the outputs.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
For making an output secure, the content-protection should be set for
each of head attached to that output. So whenever the protection for
a weston_output is desired, it means that protection is desired for
each of the weston_head attached to that weston_output.
This patch introduces a new enum in libweston to represent the
requested/current protection statuses, equivalent to the type enum
defined by the weston-secure-output protocol. The new enum helps to
extend the content-protection status and requests to libweston and
the backends.
This patch also adds a new member desired_protection to store the
desired protection for an output in weston_output.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
The xdg-output resources are listed in each head struct. They become idle when
the respective weston_output has been removed again. The client is supposed to
destroy them explicitly afterwards.
After starting an XWayland client xrandr displays the logical size as expected.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Also, add tag symbols related to 'weston_head'.
The bridge between sphinx and doxygen (breathe) has a useful directive:
doxygengroup. By using it we can scoop out symbols we'd like to display
documentation from/of.
At the same time some bits of the code has been using '\memberof' (a
doxygen command useful in C code to establish class like
relationship between objects and functions) but this seems not to be
recognized by the sphinx bridge.
Until we find a better solution, we replace '\memberof' command with
'\ingroup' one as to tag the symbols with an "object". This patch does
that for 'weston_head' object.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This fixes warnings for weston-debug, input, compositor, log and
linux-explicit-sync. Warnings range from swapping '[in]', '[out]' with
the function arguments to wrong parameter names.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
As we transition towards a more generic API for weston loggging
framework rename weston_debug_compositor to weston_log_context to show
the fact that this is not really debug but a logging context.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This patch allows initialization of weston-debug/log framework much earlier
than weston_compositor, which in turn will provide the option start
logging before weston_compositor has been created.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
The printf() format specifier "%m" is a glibc extension to print
the string returned by strerror(errno). While supported by other
libraries (e.g. uClibc and musl), it is not widely portable.
In Weston code the format string is often passed to a logging
function that calls other syscalls before the conversion of "%m"
takes place. If one of such syscall modifies the value in errno,
the conversion of "%m" will incorrectly report the error string
corresponding to the new value of errno.
Remove all the occurrences of the specifier "%m" in Weston code
by using directly the string returned by strerror(errno).
While there, fix some minor indentation issue.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
This is an installed public header, and without the subdir would surely
conflict with something else.
include/libweston/meson.build is necessary for putting the generated header in
the right subdirectory so that '#include <libweston/version.h>' can work.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The main idea is to make libweston users use the form
#include <libweston/libweston.h>
instead of the plain
#include <compositor.h>
which is prone to name conflicts. This is reflected both in the installed
files, and the internal header search paths so that Weston would use the exact
same form as an external project using libweston would.
The public headers are moved under a new top-level directory include/ to make
them clearly stand out as special (public API).
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
With the addition of patch 433f4e77b7 we display the same view id (0)
for every view as we're modifying the local variable.
Displaying sub-surfaces based views is also problematic. The caller need
to modify the view number as well, so we instead we pass the address as
to allow that to happen. Otherwise we end up repeating the same number
for views without sub-subrfaces once those have been printed.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Implement the get_release request of the zwp_surface_synchronization_v1
interface.
This commit implements the zwp_buffer_release_v1 interface. It supports
the zwp_buffer_release_v1.fenced_release event for surfaces rendered by
the GL renderer, and the zwp_buffer_release_v1.immediate_release event
for other cases.
Note that the immediate_release event is safe to be used for surface
buffers used as planes in the DRM backend, since the backend releases
them only after the next page flip that doesn't use the buffers has
finished.
Changes in v7:
- Remove "partial" from commit title and description.
- Fix inverted check when clearing used_in_output_repaint flag.
Changes in v5:
- Use the new, generic explicit sync server error reporting function.
- Introduce and use weston_buffer_release_move.
- Introduce internally and use weston_buffer_release_destroy.
Changes in v4:
- Support the zwp_buffer_release_v1.fenced_release event.
- Support release fences in the GL renderer.
- Assert that pending state buffer_release is always NULL after a
commit.
- Simplify weston_buffer_release_reference.
- Move removal of destroy listener before resource destruction to
avoid concerns about use-after-free in
weston_buffer_release_reference
- Rename weston_buffer_release_reference.busy_count to ref_count.
- Add documentation for weston_buffer_release and ..._reference.
Changes in v3:
- Raise NO_BUFFER for get_release if no buffer has been committed,
don't raise UNSUPPORTED_BUFFER for non-dmabuf buffers,
so get_release works for all valid buffers.
- Destroy the buffer_release object after sending an event.
- Track lifetime of buffer_release objects per commit, independently
of any buffers.
- Use updated protocol interface names.
- Use correct format specifier for resource ids.
Changes in v2:
- Raise UNSUPPORTED_BUFFER at commit if client has requested a
buffer_release, but the committed buffer is not a valid linux_dmabuf.
- Remove tests that are not viable anymore due to our inability to
create dmabuf buffers and fences in a unit-test environment.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Implement the set_acquire_fence request of the
zwp_surface_synchronization_v1 interface.
The implementation uses the acquire fence in two ways:
1. If the associated buffer is used as GL render source, an
EGLSyncKHR is created from the fence and used to synchronize
access.
2. If the associated buffer is used as a plane framebuffer,
the acquire fence is treated as an in-fence for the atomic
commit operation. If in-fences are not supported and the buffer
has an acquire fence, we don't consider it for plane placement.
If the used compositor/renderer doesn't support explicit
synchronization, we don't advertise the protocol at all. Currently only
the DRM and X11 backends when using the GL renderer advertise the
protocol for production use.
Issues for discussion
---------------------
a. Currently, a server-side wait of EGLSyncKHR is performed before
using the EGLImage/texture during rendering. Unfortunately, it's not clear
from the specs whether this is generally safe to do, or we need to
sync before glEGLImageTargetTexture2DOES. The exception is
TEXTURE_EXTERNAL_OES where the spec mentions it's enough to sync
and then glBindTexture for any changes to take effect.
Changes in v5:
- Meson support.
- Make explicit sync server error reporting more generic, supporting
all explicit sync related interfaces not just
wp_linux_surface_synchronization.
- Fix typo in warning for missing EGL_KHR_wait_sync extension.
- Support minor version 2 of the explicit sync protocol (i.e., support
fences for opaque EGL buffers).
Changes in v4:
- Introduce and use fd_clear and and fd_move helpers.
- Don't check for a valid buffer when updating surface acquire fence fd
from state.
- Assert that pending state acquire fence fd is always clear
after a commit.
- Clarify that WESTON_CAP_EXPLICIT_SYNC applies to just the
renderer.
- Check for EGL_KHR_wait_sync before using eglWaitSyncKHR.
- Dup the acquire fence before passing to EGL.
Changes in v3:
- Keep acquire_fence_fd in surface instead of buffer.
- Clarify that WESTON_CAP_EXPLICIT_SYNC applies to both backend and
renderer.
- Move comment about non-ownership of in_fence_fd to struct
drm_plane_state definition.
- Assert that we don't try to use planes with in-fences when using the
legacy KMS API.
- Remove unnecessary info from wayland error messages.
- Handle acquire fence for subsurface commits.
- Guard against self-update in fd_update.
- Disconnect the client if acquire fence EGLSyncKHR creation or wait
fails.
- Use updated protocol interface names.
- User correct format specifier for resource ids.
- Advertise protocol for X11 backend with GL renderer.
Changes in v2:
- Remove sync file wait fallbacks.
- Raise UNSUPPORTED_BUFFER error at commit if we have an acquire
fence, but the committed buffer is not a valid linux_dmabuf.
- Don't put buffers with in-fences on planes that don't support
in-fences.
- Don't advertise explicit sync protocol if backend does not
support explicit sync.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Introduce support for the zwp_linux_explicit_synchronization_unstable_v1
protocol with an implementation of the zwp_linux_explicit_synchronization_v1
interface.
Explicit synchronization provides a more versatile notification
mechanism for buffer readiness and availability, and can be used to
improve efficiency by integrating with related functionality in display
and graphics APIs.
In addition, the per-commit nature of the release events provided by
this protocol potentially offers a solution to a deficiency of the
wl_buffer.release event (see
https://gitlab.freedesktop.org/wayland/wayland/issues/46).
Support for this protocol depends on the capabilities of the backend, so
we don't register it by default but provide a function which each
backend will need to call. In this commit only the headless backend when
using the noop renderer supports this to enable testing.
Note that the zwp_surface_synchronization_v1 interface, which contains
the core functionality of the protocol, is not implemented in this
commit. Support for it will be added in future commits.
Changes in v7:
- Added some information in the commit message about the benefits of
the explicit sync protocol.
Changes in v6:
- Fall back to advertising minor version 1 of the explicit sync protocol,
although we support minor version 2 features, until the new
wayland-protocols version is released.
Changes in v5:
- Meson support.
- Advertise minor version 2 of the explicit sync protocol.
Changes in v4:
- Enable explicit sync support in the headless backend for all
renderers.
Changes in v3:
- Use wl_resource_get_version() instead of hardcoding version 1.
- Use updated protocol interface names.
- Use correct format specifier for resource id.
- Change test name to 'linux-explicit-synchronization.weston'
(s/_/-/g).
Changes in v2:
- Move implementation to separate file so protocol can be registered
on demand by backends.
- Register protocol in headless+noop backend for testing purposes.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Introduce a helper function to disconnect the client on unhandled
buffer types, and use it in the gl and pixman renderers. The function
is modeled after linux_dmabuf_buffer_send_server_error.
Also print the egl error state in the gl renderer, in case the
unrecognized buffer error happens when querying an egl buffer.
https://gitlab.freedesktop.org/wayland/weston/issues/148
Add non-desktop property for weston_heads representing displays that the
desktop should not be extended to by default, e.g. head mounted displays.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Use the weston_surface is_opaque property, the opaque region, and the view
alpha value to determine whether the weston_view is opaque in a specific
region.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Add an is_opaque property that is set to true if the attached buffer does not
have an alpha component, or if the solid color is non-transparent.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Add a 'scene-graph' debug scope which will dump out the current set of
outputs, layers, and views and as much information as possible about how
they are rendered and composited.
Signed-off-by: Daniel Stone <daniels@collabora.com>
As a counterpart to weston_layer_set_mask_infinite(), returning if the
mask is the same as what is set.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
weston_debug is both a libweston API for relaying debugging messages,
and the compositor-debug wayland protocol implementation for accessing those
debug messages from a Wayland client.
weston_debug_compositor_{create,destroy}() are private API, hence not
exported.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
append the debug scope name along with the timestamp in
weston_debug_scope_timestamp API
Signed-off-by: Maniraj Devadoss <Maniraj.Devadoss@in.bosch.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Add explicit advertisement of debug scope names.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Emre Ucan <eucan@de.adit-jv.com>
Since the repaint status of the flushed output may be reset if a output
repaint is failed, it is necessary to clear the repainted flag
immediately after output repaint flush/cancel.
Signed-off-by: Tomohito Esaki <etom@igel.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This is regression apparently introduced in
0de859ede4, which accidentally swapped the
sign of 'delta_width' in the original call site. If one removes an
output, the remaining outputs on the right are getting moved even
further to the right.
The outputs to the right should be moved to the left instead, to close
the gap left by the removed output.
Reported-by: Tomasz Olszak <olszak.tomasz@gmail.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Rather than having a hardcoded dependency on the build-directory layout,
use an explicit module-map environment variable, which rewrites requests
for modules and helper/libexec binaries to specific paths.
Pekka: This will help with migration to Meson where setting up the paths
according to autotools would be painful and unnecessary.
Emre: This should also help setting up the test suite after a
cross-compile.
Pekka: A caveat here is that this patch makes it slightly easier to load
external backends by abusing the module map. External backends are
specifically not supported in libweston.
Signed-off-by: Daniel Stone <daniels@collabora.com>
v2:
Fixed ivi_layout-test-plugin.c:wet_module_init().
Do not change the lookup name of ivi-layout.ivi.
Improved documentation of weston_module_path_from_env() and made it cope
with map strings that a) do not end with a semicolon, and b) have
multiple consecutive semicolons.
Let WESTON_MODULE_MAP be printed into the test log so that it is easier
to run tests manually.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Emre Ucan <eucan@de.adit-jv.com>
Suggested by Emil: Use a variable for strlen(name).
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
