Commit Graph

18 Commits

Author SHA1 Message Date
Philipp Zabel
aab722bb17 backend-drm: prepare virtual output API for heterogeneous outputs
Stop plugins from overwriting the struct weston_output::destroy vfunc,
as that will be used by backends to recognize their outputs.
Instead, pass a plugin-specific destroy callback when creating the
virtual output.

See: https://gitlab.freedesktop.org/wayland/weston/-/issues/268

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2022-06-10 09:27:43 +00:00
Marius Vlad
d284ab0322 pipewire,remoting,tests: Replace asprintf w/ str_printf
We have a string helper which wraps asprintf(). Uses that one because it
clears out the destination string, but also it won't return the number
of bytes unlinke asprintf().

Fixes warnings like:
warning: ignoring return value of ‘asprintf’ declared with attribute
‘warn_unused_result’.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
2022-03-14 15:51:09 +02:00
Emmanuel Gil Peyrot
d4a208c2b1 pipewire: Drop support for 0.2 API
According to repology.org, all relevant distributions now ship
pipewire 0.3, so we can drop the pretty ugly #if/#else code that was
added to support both at compile-time.

Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
2021-10-27 09:18:51 +00:00
Ambareesh Balaji
a67393c353 pipewire: fix null deref in 0.3 API
Signed-off-by: Ambareesh Balaji <ambareeshbalaji@gmail.com>
2021-01-12 16:02:19 +00:00
Veeresh Kadasani
9490a9893f pipewire/meson: fix option in user_hint
Signed-off-by: Veeresh Kadasani <veereshkadasani88@gmail.com>
2020-11-17 09:48:59 -05:00
Marius Vlad
bb7ed37a89 remoting,pipewire: Use the connector and the output name for the head name
Makes the client's life much easier to identify between multiple remote
outputs. xdg_output is advertising (in later versions) the head name,
but in case we have different plug-ins or multiple remote
outputs created, it would only repeat/advertise the same name
for all (remoting) outputs.

This instead uses a string that uses both the connector and name to
derive a more easier identifier a client can choose from.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
2020-11-09 11:36:12 +02:00
James Hilliard
80b585f8d2 pipewire: add support for 0.3 API
Fixes: #369

Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
2020-09-04 10:39:15 +00:00
Marius Vlad
c4076ef88a plug-ins: Migrate pipewire and remoting plug-ins headers to public header
directory

Weston is also a user of the plug-ins, so make use of it. With this
change we unconditionally install the plug-in headers even though
libweston might not be built with support for them.

Suggested-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
2020-09-04 10:36:48 +00:00
Marius Vlad
380ceee6a1 remoting, pipewire: Install pipewire and remoting plug-ins headers
Required for other users of libweston.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
2020-08-27 14:32:26 +03:00
Michael Olbrich
a24a326bb1 pipewire: implement DPMS
Pipewire doesn't need to wait for any hardware. The finish_frame() callback is
just artifically delayed to generate the desired framerate.

So when the DPMS level changes, we can just call finish_frame() immediately if
necessary and cancel the timer.

Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
2020-08-19 08:50:45 +02:00
Leandro Ribeiro
23289358af pipewire: stop direct accessing core struct member
Commit "weston-log: add function to avoid direct
access to compositor members in non-core code" added the
function weston_compositor_add_log_scope mainly to allow
libweston users to avoid direct accessing core structs, as
weston_compositor.

Replace weston_log_context_add_log_scope usage by
weston_compositor_add_log_scope.

Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
2020-01-29 09:55:24 +00:00
Leandro Ribeiro
f014964f6f weston-log: rename the confusing function name weston_compositor_log_scope_destroy()
There's a function named weston_compositor_log_scope_destroy()
but it doesn't take a struct weston_compositor argument.

Rename it to weston_log_scope_destroy(), as the argument is a
struct weston_log_scope.

Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
2020-01-27 13:43:24 -03:00
Leandro Ribeiro
5976dbbbb5 weston-log: rename the confusing function name weston_compositor_add_log_scope()
There's a function named weston_compositor_add_log_scope()
but it doesn't take a struct weston_compositor argument.

Rename it to weston_log_ctx_add_log_scope(), as
the log_scope is being added to a log_context.

Also, bump libweston_major to 9.

Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
2020-01-27 13:42:42 -03:00
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