fdo-mirrors/wireplumber
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/pipewire/wireplumber.git synced 2025-12-20 07:40:03 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
wireplumber/lib/wp/core.h

55 lines
1.6 KiB
C
Raw Normal View History

Refactor everything! After discussing things at the AGL May 2019 F2F meeting and reflecting on the initial design of WirePlumber, it became clear that it needed a fresh start.
2019-05-17 13:08:45 +03:00
/* WirePlumber
*
* Copyright © 2019 Collabora Ltd.
* @author George Kiagiadakis <george.kiagiadakis@collabora.com>
*
Relicense to MIT
2019-05-31 12:13:01 +03:00
* SPDX-License-Identifier: MIT
Refactor everything! After discussing things at the AGL May 2019 F2F meeting and reflecting on the initial design of WirePlumber, it became clear that it needed a fresh start.
2019-05-17 13:08:45 +03:00
*/
#ifndef __WIREPLUMBER_CORE_H__
#define __WIREPLUMBER_CORE_H__
#include <glib-object.h>
lib: introduce WpObjectManager * rework how global objects are stored in the core * rework how users get notified about global objects and proxies of remote global objects The purpose of this change is to have a class that can manage objects that are registered in the core or signalled through the registry. This object can declare interest on certain types of global objects and only keep & signal those objects that it is interested in. Additionally, it can prepare proxy features and asynchronously deliver an 'objects-changed' signal, which is basically telling us that the list of objects has changed. This is useful to simplify port proxies management in WpAudioStream. Now the stream object can declare that it is interested in ports that have "node.id" == X and the object manager will only maintain a list of those. Additionally, it will emit the 'objects-changed' signal when the list of ports is complete, so there is no reason to do complex operations and core syncs in the WpAudioStream class in order to figure out when the list of ports is ready. As a side effect, this also reduces resource management. Now we don't construct a WpProxy for every global that pipewire reports; we only construct proxies when there is interest in them! Another interesting side effect is that we can now register an object manager at any point in time and get immediately notified about remote globals that already exist. i.e. when you register an object manager that is interested in nodes, it will be immediately notified about all the existing nodes in the graph. This is useful to avoid race conditions between connecting the signal and objects beting created in pipewire
2019-11-13 15:44:23 +02:00
#include "object-manager.h"
lib/wp: merge both WpRemote & WpRemotePipewire in WpCore In practice we always create a remote and connect to pipewire. Any other scenario is invalid, therefore, it is not justified to be confused with so many classes for such small functionality. This simplifies a lot the modules code. Also, this commit exposes the pw_core and pw_remote objects out of WpCore. This is in practice useful when dealing with low-level pw and spa factories, which are used in the monitors. Let's not add API wrappers for everything... Bindings will never use this functionality anyway, since it depends on low level pipewire C API.
2019-09-07 17:55:46 +03:00
#include "proxy.h"
Refactor everything! After discussing things at the AGL May 2019 F2F meeting and reflecting on the initial design of WirePlumber, it became clear that it needed a fresh start.
2019-05-17 13:08:45 +03:00
G_BEGIN_DECLS
update to the latest pipewire API
2020-01-09 12:39:45 -05:00
struct pw_context;
lib/wp: merge both WpRemote & WpRemotePipewire in WpCore In practice we always create a remote and connect to pipewire. Any other scenario is invalid, therefore, it is not justified to be confused with so many classes for such small functionality. This simplifies a lot the modules code. Also, this commit exposes the pw_core and pw_remote objects out of WpCore. This is in practice useful when dealing with low-level pw and spa factories, which are used in the monitors. Let's not add API wrappers for everything... Bindings will never use this functionality anyway, since it depends on low level pipewire C API.
2019-09-07 17:55:46 +03:00
Refactor everything! After discussing things at the AGL May 2019 F2F meeting and reflecting on the initial design of WirePlumber, it became clear that it needed a fresh start.
2019-05-17 13:08:45 +03:00
#define WP_TYPE_CORE (wp_core_get_type ())
G_DECLARE_FINAL_TYPE (WpCore, wp_core, WP, CORE, GObject)
update to the latest pipewire API
2020-01-09 12:39:45 -05:00
/* Basic */
core: allow passing properties to the pw_core and pw_remote constructors
2019-09-07 18:21:17 +03:00
WpCore * wp_core_new (GMainContext *context, WpProperties * properties);
lib/wp: merge both WpRemote & WpRemotePipewire in WpCore In practice we always create a remote and connect to pipewire. Any other scenario is invalid, therefore, it is not justified to be confused with so many classes for such small functionality. This simplifies a lot the modules code. Also, this commit exposes the pw_core and pw_remote objects out of WpCore. This is in practice useful when dealing with low-level pw and spa factories, which are used in the monitors. Let's not add API wrappers for everything... Bindings will never use this functionality anyway, since it depends on low level pipewire C API.
2019-09-07 17:55:46 +03:00
GMainContext * wp_core_get_context (WpCore * self);
update to the latest pipewire API
2020-01-09 12:39:45 -05:00
struct pw_context * wp_core_get_pw_context (WpCore * self);
/* Connection */
gboolean wp_core_connect (WpCore *self);
void wp_core_disconnect (WpCore *self);
gboolean wp_core_is_connected (WpCore * self);
/* Callback */
core: change idle_add to take a GDestroyNotify as well and return a source id to make it more usable and compatible with g_idle_add
2019-12-12 20:07:46 +02:00
guint wp_core_idle_add (WpCore * self, GSourceFunc function, gpointer data,
GDestroyNotify destroy);
core: return a boolean in sync API
2019-12-06 08:43:40 -05:00
gboolean wp_core_sync (WpCore * self, GCancellable * cancellable,
core: add sync API
2019-12-04 15:20:42 -05:00
GAsyncReadyCallback callback, gpointer user_data);
lib/wp: merge both WpRemote & WpRemotePipewire in WpCore In practice we always create a remote and connect to pipewire. Any other scenario is invalid, therefore, it is not justified to be confused with so many classes for such small functionality. This simplifies a lot the modules code. Also, this commit exposes the pw_core and pw_remote objects out of WpCore. This is in practice useful when dealing with low-level pw and spa factories, which are used in the monitors. Let's not add API wrappers for everything... Bindings will never use this functionality anyway, since it depends on low level pipewire C API.
2019-09-07 17:55:46 +03:00
update to the latest pipewire API
2020-01-09 12:39:45 -05:00
/* Object */
WpProxy * wp_core_export_object (WpCore * self, const gchar * interface_type,
core: add wp_core_export_object API
2020-01-09 09:20:50 -05:00
gpointer local_object, WpProperties * properties);
core: add wp_core_create_local_object API
2020-01-08 09:48:35 -05:00
WpProxy * wp_core_create_local_object (WpCore * self,
update to the latest pipewire API
2020-01-09 12:39:45 -05:00
const gchar *factory_name, const gchar * interface_type,
core: add wp_core_create_local_object API
2020-01-08 09:48:35 -05:00
guint32 interface_version, WpProperties * properties);
lib/wp: merge both WpRemote & WpRemotePipewire in WpCore In practice we always create a remote and connect to pipewire. Any other scenario is invalid, therefore, it is not justified to be confused with so many classes for such small functionality. This simplifies a lot the modules code. Also, this commit exposes the pw_core and pw_remote objects out of WpCore. This is in practice useful when dealing with low-level pw and spa factories, which are used in the monitors. Let's not add API wrappers for everything... Bindings will never use this functionality anyway, since it depends on low level pipewire C API.
2019-09-07 17:55:46 +03:00
WpProxy * wp_core_create_remote_object (WpCore * self,
update to the latest pipewire API
2020-01-09 12:39:45 -05:00
const gchar * factory_name, const gchar * interface_type,
lib/wp: merge both WpRemote & WpRemotePipewire in WpCore In practice we always create a remote and connect to pipewire. Any other scenario is invalid, therefore, it is not justified to be confused with so many classes for such small functionality. This simplifies a lot the modules code. Also, this commit exposes the pw_core and pw_remote objects out of WpCore. This is in practice useful when dealing with low-level pw and spa factories, which are used in the monitors. Let's not add API wrappers for everything... Bindings will never use this functionality anyway, since it depends on low level pipewire C API.
2019-09-07 17:55:46 +03:00
guint32 interface_version, WpProperties * properties);
update to the latest pipewire API
2020-01-09 12:39:45 -05:00
/* Object Manager */
lib: introduce WpObjectManager * rework how global objects are stored in the core * rework how users get notified about global objects and proxies of remote global objects The purpose of this change is to have a class that can manage objects that are registered in the core or signalled through the registry. This object can declare interest on certain types of global objects and only keep & signal those objects that it is interested in. Additionally, it can prepare proxy features and asynchronously deliver an 'objects-changed' signal, which is basically telling us that the list of objects has changed. This is useful to simplify port proxies management in WpAudioStream. Now the stream object can declare that it is interested in ports that have "node.id" == X and the object manager will only maintain a list of those. Additionally, it will emit the 'objects-changed' signal when the list of ports is complete, so there is no reason to do complex operations and core syncs in the WpAudioStream class in order to figure out when the list of ports is ready. As a side effect, this also reduces resource management. Now we don't construct a WpProxy for every global that pipewire reports; we only construct proxies when there is interest in them! Another interesting side effect is that we can now register an object manager at any point in time and get immediately notified about remote globals that already exist. i.e. when you register an object manager that is interested in nodes, it will be immediately notified about all the existing nodes in the graph. This is useful to avoid race conditions between connecting the signal and objects beting created in pipewire
2019-11-13 15:44:23 +02:00
void wp_core_install_object_manager (WpCore * self, WpObjectManager * om);
Refactor everything! After discussing things at the AGL May 2019 F2F meeting and reflecting on the initial design of WirePlumber, it became clear that it needed a fresh start.
2019-05-17 13:08:45 +03:00
G_END_DECLS
#endif
Reference in a new issue Copy permalink