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>
Extend the existing output-damage test to test
blit_shadow_to_output() specifically. This function had problems
originally, so make sure they can't reappear.
The added quirk is explained in the test.
An additional check of the quirk in gl_renderer_output_create() ensures
that the shadow framebuffer is really used. The test could false-pass if
the shadow is not used.
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>
This test ensures that client submitted damage goes to the screen
correctly, regardless of output scale or transform.
The added quirk is explained in the test that uses it.
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>
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>
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_destroy(), which destroys struct
weston_log_context, takes weston_compositor as argument. We may have a
weston_log_context unlinked from a weston_compositor and currently there
is no way to destroy it.
Add function weston_log_ctx_destroy(), what makes the destruction of
weston_log_context independent of weston_compositor.
With this change, one could destroy a weston_compositor and keep the
related weston_log_context (since now weston_log_context can be destroyed
without the need of a weston_compositor). But if weston_compositor gets
destroyed it's also necessary to destroy weston_log_context::global,
as the debug protocol depends on the compositor. So a listener has been
added to the destroy signal of weston_compositor.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Since weston_log_ctx_compositor_create() does not have any relation
with weston_compositor, rename it to weston_log_ctx_create().
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
When we were designing the libweston output API, I wrote a design document
as a Phabricator wiki page. Phabricator is no longer accessible so that
information needs to be migrated to a new place. Here I am converting most of
it into libweston Sphinx documentation, particularly pulling in the sequence
diagrams I drew. This should help people understand how libweston output
configuration works.
The diagrams are committed as both MSC source files and rendered PNG files. I
did not bother tinkering with the build to run mscgen automatically and then
with the CI images to install the tool.
The Sphinx configuration need numref explicitly enabled so that figures are
automatically numbered and can be referenced by their number rather than their
whole caption text(!).
The document structure is changed a little better flowing with Output
Management being the overview page and the Heads and Outputs being the API
pages.
First I wrote the struct weston_output and weston_head descriptions in Doxygen
comments in libweston.h, but then in the API page that text would have been
buried somewhere towards the end of the page. So I put that text in ReST
instead where it comes as first on the pages as it should. The doc for the
structs only contain a link to the top of the page. Yes, the comment style in
libweston.h is a little broken. If I left the asterisk there it would show up
as a bullet point in Sphinx. OTOH putting everything from \rst in a single line
did not produce anything.
Because Sphinx cannot look in two places, the images need to be copied into the
build dir too.
mscgen: http://www.mcternan.me.uk/mscgen/
Fixes: https://gitlab.freedesktop.org/wayland/weston/issues/25
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
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>
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>
Since version 7 clients must use MAP_PRIVATE to map the keymap fd so we
can use memfd_create in os_ro_anonymous_file_get_ref using
RO_ANONYMOUS_FILE_MAPMODE_PRIVATE, for older version we use
RO_ANONYMOUS_FILE_MAPMODE_SHARED to be compatibile with MAP_SHARED.
Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>
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>
For supporting output layout, compositors need the ability to manually set the
'weston_output' by 'weston_output_move'.
Signed-off-by: sichem <sichem.zh@gmail.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>
Introduce a new private header file that only internal backends are
allowed to use. Starts by migrating functions that operate on the
'struct weston_head'.
Signed-off-by: Marius Vlad <marius.vlad@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>
config-parser.h is a helper API that libweston core must never depend on. Using
it is a compositor frontend decision.
Including it in libweston.h would give the wrong message.
Signed-off-by: Pekka Paalanen <pekka.paalanen@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>
