Commit graph

4 commits

Author SHA1 Message Date
Pekka Paalanen 6ffbba3ac1 Use weston_compositor_add_destroy_listener_once() in plugins
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>
2019-11-21 16:32:55 +00:00
Pekka Paalanen 3d5d9476e3 Rename compositor.h to libweston/libweston.h
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>
2019-04-18 12:31:46 +03:00
Quentin Glidic 8af2beccbd
weston: Properly namespace modules entrypoint
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
2017-01-17 18:24:56 +01:00
Pekka Paalanen 58f98c99f5 Move weston source to compositor/
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]
2016-06-23 17:44:54 +03:00
Renamed from src/cms-static.c (Browse further)