Commit Graph

5 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
71ff95a544 build: separate deps for int and ext libweston users
We have two kinds of libweston users: internal and external. Weston, the
frontend, counts as an external user, and should not have access to libweston
private headers. The shell plugins are external users as well, because we
intend people to be able to write them. Renderers, backends, and some plugins
are internal users who will need access to private headers.

Create two different Meson dependency objects, one for each kind.

This makes it less likely to accidentally use a private header.

Screen-share is a Weston plugin and therefore counts as an external user, but
it needs the backend API to deliver input. Until we are comfortable exposing
public API for that purpose, let it use internal headers.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-10-24 13:29:33 +03:00
Marius Vlad
9bb1c3a3c2 weston-log: Add 'destroy_subscription' callback for the subscription
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>
2019-10-17 19:42:55 +03:00
Pekka Paalanen
4f5e360180 build: simplify include_directories
Define common_inc which includes both public_inc and the project root directory.
The project root directory will allow access to config.h and all the shared/
headers.

Replacing all custom '.', '..', '../..', '../shared' etc. include paths with
common_inc reduces clutter in the target definitions and enforces the common
 #include directive style, as e.g. including shared/ headers without the
subdirectory name no longer works.

Unfortunately this does not prevent one from using private libweston headers
with the usual include pattern for public headers.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-10-04 17:14:22 +03:00
Michael Olbrich
d5d5aa91a2 Add pipewire plugin
It is quite similar to the remoting plugin. It just exports the frames via
pipewire instead of the builtin GStreamer pipeline.
It implements the same virtual output API. Virtual outputs can be created
by adding 'pipewire-output' sections to weston.ini.

The generated frames can be accessed with any pipewire client. e.g. with
GStreamer:

gst-launch-1.0 pipewiresrc ! video/x-raw,format=BGRx ! ...

Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
2019-07-19 08:01:55 +02:00