It's currently assumed by backends that renderers discard
renderbuffers on resize. This commit introduces a new
weston_renderbuffer_discarded_func callback that must be passed at
renderbuffer creation in order to be notified of discarded events from
the renderer. This discarded event could potentially be reused later
by renderers on other occasions without having to change backends once
they get proper support for that.
On output resize, once a discarded event handler fails (returns false)
on a renderbuffer, all the remaining renderbuffers in the output list
go stale and weston_renderer_resize_output() ultimately returns false
for backends to be notified of the failure.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Renderbuffers currently have a libweston-internal base data structure
with a ref-counting system to handle their lifetime. The problem is
that renderers keep a ref to all renderbuffers in a list per output
(to deal with damages) and that it prevents backends from releasing
renderbuffer resources when not needed anymore. Renderbuffers are then
only released (last ref removed) when the output is destroyed or
resized. dma-buf renderbuffers even expose a dedicated function
remove_renderbuffer_dmabuf() to explictly request the release of their
resources.
This commit proposes to get rid of the ref-counting system by exposing
a single entry point to explicitly destroy all types of renderbuffers
from the renderer.
Instead of removing a renderbuffer from its output list and dropping
its ref when the output is resized, this commit also introduces the
concept of stale renderbuffers which consists in releasing the
resources of a renderbuffer when it's discarded by the renderer while
keeping it in the output list, with a stale state, until it's
explicitly destroyed.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Move the responsibility for damaging the entire area of new
renderbuffers from backends to renderers.
There's one little drawback: VNC damage logging can't log the
accumulated renderbuffer damage anymore, but I guess this should
somehow be done as an option in the renderers.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
This adds tests to create image descriptions through color parameters
using the CM&HDR protocol extension.
The code for that was added in commit "color: allow clients to create
image description from parameters".
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Start to print the parameters from struct cmlcms_color_profile::params
in cmlcms_color_profile_print(). This will be useful for the next
commit, in which we add tests that craft parametric color profiles.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
A counter instead of a boolean should be useful when we add code
printing the parameters. This should help us to avoid printing unused
parameters.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Commit "color: add support to the color-management protocol" added
support for the majority of the interfaces from the color-management
protocol.
The missing part was the interface that allows clients to create image
descriptions from parameters. In this patch we do that.
For now this just exercises the mechanical aspects of the protocol, we
still need to write the code to create proper color profiles from that
and make use of them in our codebase.
In the next commits we add a new test file with lots of tests exercising
the creation of image descriptions through parameters.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
If a certain feature is unsupported, return UNSUPPORTED instead of
BAD_TF, BAD_PRIMARIES, etc.
Also, up to now cm->get_color_profile_from_params() would return
UNSUPPORTED. But this is different from the other UNSUPPORTED usages, so
return a new error.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In the parametric builder API, which is used by our color management
protocol implementation, we have errors that may be translated to
protocol errors or graceful failures. As we return a single err code
to the protocol implementation, let's prioritize the protocol error.
We do that by inverting the order of checks, as the first error code
caught is the one prioritized.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This follows a recent change in the CM&HDR protocol (more specifically,
v4 of the experimental version). Now users of the API can set luminance
parameters for the primary color volume.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This follows a recent change in the CM&HDR protocol (more specifically,
v4 of the experimental version). Now clients can use the protocol to set
luminance parameters for the primary color volume.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
The CM&HDR protocol extension spec relaxed the requirements for the
max_fall and max_cll setters. Now we accept such values even when the
transfer function is not PQ.
This also fixes an issue in which we'd not accept target_luminance
for transfer function different from PQ, which was not on the spec.
INCONSISTENT_SET is not being used in any other errors, so remove that
from enum weston_color_profile_param_builder_error.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In the experimental color-management protocol v3
(xx-color-management-v3), we had only the luminance parameters that were
defining the luminance range targeted by the image description. But in
v4 a way to specify luminance parameters for the primary color volume
has been added.
In order to avoid confusion, rename existent luminance variables to
target luminance.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
While choosing a name for file color-properties.h, I've had originally
opted for color-characteristics.h. But we already have some other stuff
named color characteristics in the code, so I've changed that to
color-properties.h.
This fixes a leftover from that. Rename WESTON_COLOR_CHARACTERISTICS_H
to WESTON_COLOR_PROPERTIES_H.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
We need this common helper as we don't have access to shared helper, so
just define one in-situ.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This is problematic as we don't have namespacing for these and some of
the macros can interfere with other defines.
This reverts commit 8634c7e349.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Fix weston crash when user click the mouse continuosly while
the video is playing.
Call weston_view_update_transform before calling
weston_coord_global_to_surface to update view->transform.dirty to 0.
Fixes#985
Tested-by: Sooyeon Kang sooyeon8979@gmail.com
Signed-off-by: Sooyeon Kang sooyeon8979@gmail.com
Up to now, we've been logging only the failures that we get from
drm_fb_get_from_paint_node(). So let's start logging the other failures
we get in drm_output_find_plane_for_view() as well.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This should help people to debug. Instead of printing an hex value,
print each enum value present in the bitmask as a string (comma
separated).
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This function is useful across multiple components of the project, so
move it to a helper header.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Client won't be able to do direct-scanout with this surface, and the
format/modifier doesn't matter in this case. So let's remove the scanout
tranche from dma-buf feedback in such case.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Currently we have the following situation: we add a scanout tranche
because if the client re-allocates with another format/modifier, the
chances of being placed in a DRM/KMS plane is higher.
But then we run out of overlay planes. So we remove the scanout tranche,
because the format/modifier available in the renderer tranche are
optimal for rendering.
Now Weston detects again that the format/modifier is what may be
avoiding the view being place in a plane, re-adding the scanout tranche.
And we have an endless loop.
To avoid this, let's accumulate the reasons why placing the view in a
place failed. So if we detect that we don't have planes available, no
matter the format/modifier, we won't add the scanout tranche.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
FAILURE_REASONS_ADD_FB_FAILED is defined as (1 << 3), so when we are
accumulating "failure reasons" in a variable we don't need to do the bit
shift again.
This results in an issue, because (1 << FAILURE_REASONS_ADD_FB_FAILED)
results in (1 << (1 << 3)) == (1 << 8).
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
There are a few points in the code where we are wrongly using
FAILURE_REASONS_ADD_FB_FAILED, probably because we didn't have so many
"failure reasons" previously. This update such cases to use enum's that
make sense.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Do not skip all the planes if a single one of them do not support
fences. The other may do.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This flag ensures support for both the GL_ANDROID_native_fence_sync
and the GL_EXT_disjoint_timer_query extensions at run-time. The GL
features log now reports that flag so the warning log has been
removed.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Storing GL function pointers along with their associated extension
name allows to better track the function pointers declared.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Now that the GL extensions are stored in the gl_extensions bitfield,
there's no need to use booleans anymore.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
This commit ensures GL_OES_EGL_image is available before setting up
dma-buf renderer functions because it's not implied by the presence of
the EGL_EXT_image_dma_buf_import extension.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
GL_OES_texture_3D isn't used because of the complexity implied for
correct OpenGL ES 2 support (see commit 734c2278), so there's no need
to check for it. The check also now avoids checking for
GL_EXT_color_buffer_half_float on OpenGL ES 3.2 which includes support
for 16-bit FP renderbuffers by default.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
The GL renderer supports OpenGL ES from version 2.0 to 3.2. It's meant
to correctly link on systems with only OpenGL ES 2, so OpenGL ES 3
symbols can't be used directly. eglGetProcAddress() is currently
defined to not support the querying of non-extension OpenGL ES
functions. Support for that is exposed by the
KHR_get_all_proc_addresses extension. This commit ensures OpenGL ES 3
function addresses can be retrieved by eglGetProcAddress() by checking
for that extension at run-time.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
A new gl_extensions bitfield is added to the renderer to store the
flags supported by the GL implementation. This allows the GL renderer
to easily check for extension support whenever needed.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Don't flag EGL_PBUFFER_BIT to get the EGL config if the
EGL_KHR_surfaceless_context extension isn't available. The branch is
never taken because the extension is required and if it isn't
available, the function would have already returned.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Get the EGL_WL_bind_wayland_display extension function addresses after
checking for extension availability.
Let the EGL display setup end before trying to bind the Wayland
display in gl-renderer.c. The EGL features log will now report the
extension as supported even if the bind subsequently fails, in which
case a warning is logged.
This commit also avoids calling query_buffer() if the display isn't
bound in fill_buffer_info(), it would otherwise fail or even segfault
if the EGL_WL_bind_wayland_display extension isn't available.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
OpenGL ES 2 and some attributes like EGL_RENDERABLE_TYPE are supported
by EGL from version 1.2.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
This feature flag is for explicit sync support.
We replace the explicit sync warning by logging supported fence syncs
along with the report EGL features report.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Trying to follow the principle presented previously, this commit
ensures extension function addresses are retrieved once their
associated extension has been checked for availability.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Get eglCreateImageKHR() and eglDestroyImageKHR() function addresses
depending on EGL_KHR_image_base availability.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
This second feature flag ensures that either the
EGL_EXT_swap_buffers_with_damage or EGL_EXT_swap_buffers_with_damage
extension is available.
Some function pointer addresses are currently retrieved depending on
the availabilty of their associated extension and some others are
retrieved unconditionally. For consistency reasons, we'll try from now
on in this commit set to first load function pointers depending on the
associated extension availability and then flag features once all the
addresses are retrieved.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
This commit introduces feature flags. While an extension flag only
ensures the availability of an extension at run-time, a feature flag
ensures the availability of a minimal OpenGL ES version and/or
extensions in order to easily check for the availability of a specific
feature at run-time.
This first feature ensures the availability of either the
EGL_KHR_no_config_context or EGL_MESA_configless_context extensions.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
A new GET_PROC_ADDRESS() macro is added to get a function address at
run-time using eglGetProcAddress() and to assert() the address isn't
NULL at once.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Storing EGL function pointers along with their associated extension
name allows to better track the function pointers declared.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
