wireplumber/lib/wp/core.h

167 lines
3.5 KiB
C
Raw Normal View History

/* WirePlumber
*
* Copyright © 2019 Collabora Ltd.
* @author George Kiagiadakis <george.kiagiadakis@collabora.com>
*
2019-05-31 12:13:01 +03:00
* SPDX-License-Identifier: MIT
*/
#ifndef __WIREPLUMBER_CORE_H__
#define __WIREPLUMBER_CORE_H__
#include "object.h"
#include "properties.h"
#include "spa-json.h"
conf: refactor configuration loading Changes: - Configuration files are no longer located by libpipewire, which allows us to control the paths that are being looked up. This is a requirement for installations where pipewire and wireplumber are built using different prefixes, in which case the configuration files of wireplumber end up being installed in a place that libpipewire doesn't look into... - The location of conf files is now again $prefix/share/wireplumber, /etc/wireplumber and $XDG_CONFIG_HOME/wireplumber, instead of using the pipewire directories. Also, since the previous commits, we now also support $XDG_CONFIG_DIRS/wireplumber (typically /etc/xdg/wireplumber) and $XDG_DATA_DIRS/wireplumber for system-wide configuration. - Since libpipewire doesn't expose the parser, we now also do the parsing of sections ourselves. This has the advantage that we can optimize it a bit for our use case. - The WpConf API has changed to not be a singleton and it is a property of WpCore instead. The configuration is now expected to be opened before the core is created, which allows the caller to identify configuration errors in advance. By not being a singleton, we can also reuse the WpConf API to open other SPA-JSON files. - WpConf also now has a lazy loading mechanism. The configuration files are mmap'ed and the various sections are located in advance, but not parsed until they are actually requested. Also, the sections are not copied in memory, unlike what happens in libpipewire. They are only copied when merging is needed. - WpCore now disables loading of a configuration file in pw_context, if a WpConf is provided. This is to have complete control here. The 'context.spa-libs' and 'context.modules' sections are still loaded, but we load them in WpConf and pass them down to pw_context for parsing. If a WpConf is not provided, pw_context is left to load the default configuration file (client.conf normally).
2024-02-28 12:11:38 +02:00
#include "conf.h"
G_BEGIN_DECLS
2020-01-09 12:39:45 -05:00
struct pw_context;
struct pw_core;
typedef struct _WpObjectManager WpObjectManager;
/*!
* \brief Flags to be used as WpObjectFeatures on WpCore
* \ingroup wpcore
*/
typedef enum { /*< flags >*/
/*! connects to pipewire */
WP_CORE_FEATURE_CONNECTED = (1 << 0),
/*! loads components defined in the configuration */
WP_CORE_FEATURE_COMPONENTS = (1 << 1),
} WpCoreFeatures;
/*!
* \brief The WpCore GType
* \ingroup wpcore
*/
#define WP_TYPE_CORE (wp_core_get_type ())
WP_API
G_DECLARE_FINAL_TYPE (WpCore, wp_core, WP, CORE, WpObject)
2020-01-09 12:39:45 -05:00
/* Basic */
WP_API
conf: refactor configuration loading Changes: - Configuration files are no longer located by libpipewire, which allows us to control the paths that are being looked up. This is a requirement for installations where pipewire and wireplumber are built using different prefixes, in which case the configuration files of wireplumber end up being installed in a place that libpipewire doesn't look into... - The location of conf files is now again $prefix/share/wireplumber, /etc/wireplumber and $XDG_CONFIG_HOME/wireplumber, instead of using the pipewire directories. Also, since the previous commits, we now also support $XDG_CONFIG_DIRS/wireplumber (typically /etc/xdg/wireplumber) and $XDG_DATA_DIRS/wireplumber for system-wide configuration. - Since libpipewire doesn't expose the parser, we now also do the parsing of sections ourselves. This has the advantage that we can optimize it a bit for our use case. - The WpConf API has changed to not be a singleton and it is a property of WpCore instead. The configuration is now expected to be opened before the core is created, which allows the caller to identify configuration errors in advance. By not being a singleton, we can also reuse the WpConf API to open other SPA-JSON files. - WpConf also now has a lazy loading mechanism. The configuration files are mmap'ed and the various sections are located in advance, but not parsed until they are actually requested. Also, the sections are not copied in memory, unlike what happens in libpipewire. They are only copied when merging is needed. - WpCore now disables loading of a configuration file in pw_context, if a WpConf is provided. This is to have complete control here. The 'context.spa-libs' and 'context.modules' sections are still loaded, but we load them in WpConf and pass them down to pw_context for parsing. If a WpConf is not provided, pw_context is left to load the default configuration file (client.conf normally).
2024-02-28 12:11:38 +02:00
WpCore * wp_core_new (GMainContext * context, WpConf * conf,
WpProperties * properties);
2020-06-10 12:27:39 -04:00
WP_API
WpCore * wp_core_clone (WpCore * self);
WP_API
WpCore * wp_core_get_export_core (WpCore * self);
conf: refactor configuration loading Changes: - Configuration files are no longer located by libpipewire, which allows us to control the paths that are being looked up. This is a requirement for installations where pipewire and wireplumber are built using different prefixes, in which case the configuration files of wireplumber end up being installed in a place that libpipewire doesn't look into... - The location of conf files is now again $prefix/share/wireplumber, /etc/wireplumber and $XDG_CONFIG_HOME/wireplumber, instead of using the pipewire directories. Also, since the previous commits, we now also support $XDG_CONFIG_DIRS/wireplumber (typically /etc/xdg/wireplumber) and $XDG_DATA_DIRS/wireplumber for system-wide configuration. - Since libpipewire doesn't expose the parser, we now also do the parsing of sections ourselves. This has the advantage that we can optimize it a bit for our use case. - The WpConf API has changed to not be a singleton and it is a property of WpCore instead. The configuration is now expected to be opened before the core is created, which allows the caller to identify configuration errors in advance. By not being a singleton, we can also reuse the WpConf API to open other SPA-JSON files. - WpConf also now has a lazy loading mechanism. The configuration files are mmap'ed and the various sections are located in advance, but not parsed until they are actually requested. Also, the sections are not copied in memory, unlike what happens in libpipewire. They are only copied when merging is needed. - WpCore now disables loading of a configuration file in pw_context, if a WpConf is provided. This is to have complete control here. The 'context.spa-libs' and 'context.modules' sections are still loaded, but we load them in WpConf and pass them down to pw_context for parsing. If a WpConf is not provided, pw_context is left to load the default configuration file (client.conf normally).
2024-02-28 12:11:38 +02:00
WP_API
WpConf * wp_core_get_conf (WpCore * self);
WP_API
GMainContext * wp_core_get_g_main_context (WpCore * self);
WP_API
2020-01-09 12:39:45 -05:00
struct pw_context * wp_core_get_pw_context (WpCore * self);
WP_API
struct pw_core * wp_core_get_pw_core (WpCore * self);
WP_API
gchar *wp_core_get_vm_type (WpCore *self);
2020-01-09 12:39:45 -05:00
/* Connection */
WP_API
2020-01-09 12:39:45 -05:00
gboolean wp_core_connect (WpCore *self);
WP_API
gboolean wp_core_connect_fd (WpCore *self, int fd);
WP_API
2020-01-09 12:39:45 -05:00
void wp_core_disconnect (WpCore *self);
WP_API
2020-01-09 12:39:45 -05:00
gboolean wp_core_is_connected (WpCore * self);
/* Properties */
WP_API
guint32 wp_core_get_own_bound_id (WpCore * self);
WP_API
guint32 wp_core_get_remote_cookie (WpCore * self);
WP_API
const gchar * wp_core_get_remote_name (WpCore * self);
WP_API
const gchar * wp_core_get_remote_user_name (WpCore * self);
WP_API
const gchar * wp_core_get_remote_host_name (WpCore * self);
WP_API
const gchar * wp_core_get_remote_version (WpCore * self);
WP_API
WpProperties * wp_core_get_remote_properties (WpCore * self);
WP_API
WpProperties * wp_core_get_properties (WpCore * self);
WP_API
void wp_core_update_properties (WpCore * self, WpProperties * updates);
2020-01-09 12:39:45 -05:00
/* Callback */
WP_API
void wp_core_idle_add (WpCore * self, GSource **source, GSourceFunc function,
gpointer data, GDestroyNotify destroy);
2020-02-12 13:20:17 -05:00
WP_API
void wp_core_idle_add_closure (WpCore * self, GSource **source,
GClosure * closure);
WP_API
void wp_core_timeout_add (WpCore * self, GSource **source, guint timeout_ms,
2020-02-12 13:20:17 -05:00
GSourceFunc function, gpointer data, GDestroyNotify destroy);
WP_API
void wp_core_timeout_add_closure (WpCore * self, GSource **source,
guint timeout_ms, GClosure * closure);
WP_API
2019-12-06 08:43:40 -05:00
gboolean wp_core_sync (WpCore * self, GCancellable * cancellable,
2019-12-04 15:20:42 -05:00
GAsyncReadyCallback callback, gpointer user_data);
WP_API
gboolean wp_core_sync_closure (WpCore * self, GCancellable * cancellable,
GClosure * closure);
WP_API
gboolean wp_core_sync_finish (WpCore * self, GAsyncResult * res,
GError ** error);
/* Object Registry */
WP_API
gpointer wp_core_find_object (WpCore * self, GEqualFunc func,
gconstpointer data);
WP_API
void wp_core_register_object (WpCore * self, gpointer obj);
WP_API
void wp_core_remove_object (WpCore * self, gpointer obj);
2020-01-09 12:39:45 -05:00
/* Object Manager */
WP_API
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);
/* Global Features */
WP_API
gboolean wp_core_test_feature (WpCore * self, const gchar * feature);
G_END_DECLS
#endif