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>
This was forgetting to remove the compositor destroy listener, which would lead
to use-after-free on compositor tear-down especially on cms-colord init failure
paths. Found by inspection.
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>
The 'head' member of 'struct weston_output' is going to go unused and
then disappear, so stop using it and find a head from the proper list.
However, this leaves a problem in cms-colord: if you have multiple
monitors driver with the same CRTC, what do you say to the color
management system? The monitors could be different, but all the color
LUTs etc. are in the CRTC and are shared, as is the framebuffer.
Do the simple hack here and just use whatever head happens to be the
first in the list.
The warning is printed in get_output_id(), because if heads are added or
removed while the output is enabled, the id could change.
v6:
- add weston_output_get_first_head(), at first use
- add warning message for nr. heads > 1
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
In order to support clone modes, libweston needs the concept of a head
that is separate from weston_output. While weston_output manages buffers
and the repaint state machine, weston_head will represent a single
monitor. In the future it will be possible to have a single
weston_output drive one or more weston_heads for a clone mode that
shares the framebuffers between all cloned heads.
All the fields that are obviously properties of the monitor are moved
from weston_output into weston_head.
As moving the fields requires one to touch all the backends for all the
assingments, introduce setter functions for them while we are here. The
setters are identical to the old assignments, for now.
As a temporary measure, weston_output embeds a single head. Also the
ugly casts in weston_head_set_monitor_strings() will be removed by a
follow-up patch.
Libweston major version is bumped, because weston_output struct layout
is changed.
v7:
- Bump libweston major version.
v6:
- adapt to upstream changes in weston_output_set_transform()
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v5 Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
v6 Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Use different functions so we cannot load a libweston common module in
weston directly or the other way around.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
This is the start of separating weston-the-compositor source files from
libweston source files.
This is moving all the files related to the 'weston' binary. Also the
CMS and systemd plugins are moved.
xwayland plugin is not moved, because it will be turned into a
libweston feature.
To avoid breaking the build, #includes for weston.h are fixed to use
compositor/weston.h. This serves as a reminder that such files may need
further attention: moving to the right directory, or maybe using the
proper -I flags instead.
v2: Move also screen-share.c, and add a note about weston-launch.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Tested-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Tested-by: Benoit Gschwind <gschwind@gnu-log.net>
Acked-by: Benoit Gschwind <gschwind@gnu-log.net>
[Pekka: rebased]
cms-colord used the weston_compositor destroy signal to
trigger its final colord_module_destroy cleanup, and the
wl_output destroy signal to trigger per output cleanup.
The problem is that the compositor destroy signal gets
emitted before the output destroy signals at compositor
shutdown, colord_module_destroy would free all its
shared data structures and then later on the output
destroy callback would try to access those shared
data structures when handling output destruction
-> Use after free -> Crash, usually with VT switching
dead and thereby an unuseable system requiring a reboot.
Solve this by moving the output destruction handling into
the colord_cms_output_destroy() cleanup function for
colord-cms own hash dictionary of all active outputs.
The output destroy callback just removes the corresponding
output from the dictionary and triggers proper cleanup if
an output is unplugged during runtime. During compositor
shutdown, the dictionary as a whole is released before
releasing all other shared data structures, thereby
triggering cleanup of all remaining outputs.
Tested to fix crashes on x11 and drm backends.
v2: Formatting: Wrap lines to < 80 characters, as suggested
by Derek. Thanks.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Removed duplicate definitions of the container_of() macro and
refactored sources to use the single implementation.
Signed-off-by: Jon A. Cruz <jonc@osg.samsung.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Using the x11 output (maybe with others as well), weston would hang
when closing the output if the colord plugin is enabled.
The hang occurs in mutex lock in the output notifier handler because
the given GMutex value is incorrect.
This is because of a cast error, the type of container should be
"cms_output" and not "cms_colord".
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Richard Hughes <richard@hughsie.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
For functions that test if something is true/valid and return a 1
or 0, it makes sense to switch to bool.
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This allows users to change the assigned display profile in GNOME (using
gnome-control-center) or KDE (using colord-kde) and also allows the profiling
tools to correctly inhibit the calibration state whilst measuring the native
screen response.
Pekka Paalanen
Pekka Paalanen
Quentin Glidic
Jussi Kukkonen
Bryce Harrington
Chris Michael
Mario Kleiner
Jon Cruz
Olivier Fourdan
Derek Foreman
Peter Hutterer
Armin K
Richard Hughes