2019-09-24 16:34:18 +03:00
|
|
|
/* WirePlumber
|
|
|
|
|
*
|
2020-02-11 16:43:10 +02:00
|
|
|
* Copyright © 2019-2020 Collabora Ltd.
|
2019-09-24 16:34:18 +03:00
|
|
|
* @author George Kiagiadakis <george.kiagiadakis@collabora.com>
|
|
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: MIT
|
|
|
|
|
*/
|
|
|
|
|
|
2020-02-17 15:39:19 +02:00
|
|
|
/**
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
* SECTION: session
|
|
|
|
|
* @title: PipeWire Session
|
2020-02-17 15:39:19 +02:00
|
|
|
*/
|
|
|
|
|
|
2020-04-14 18:31:17 +03:00
|
|
|
#define G_LOG_DOMAIN "wp-session"
|
|
|
|
|
|
2020-05-03 19:42:42 +03:00
|
|
|
#include "session.h"
|
2020-11-16 10:35:50 +02:00
|
|
|
#include "object-manager.h"
|
2020-02-11 16:43:10 +02:00
|
|
|
#include "error.h"
|
2020-11-25 14:02:33 +02:00
|
|
|
#include "debug.h"
|
2019-09-24 16:34:18 +03:00
|
|
|
#include "wpenums.h"
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
#include "private/pipewire-object-mixin.h"
|
2019-09-24 16:34:18 +03:00
|
|
|
|
|
|
|
|
#include <pipewire/extensions/session-manager.h>
|
2020-04-01 13:06:18 +03:00
|
|
|
#include <pipewire/extensions/session-manager/introspect-funcs.h>
|
|
|
|
|
|
2019-09-24 16:34:18 +03:00
|
|
|
enum {
|
2020-05-03 19:42:42 +03:00
|
|
|
SIGNAL_ENDPOINTS_CHANGED,
|
|
|
|
|
SIGNAL_LINKS_CHANGED,
|
2019-09-24 16:34:18 +03:00
|
|
|
N_SIGNALS,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static guint32 signals[N_SIGNALS] = {0};
|
|
|
|
|
|
2020-02-11 16:43:10 +02:00
|
|
|
typedef struct _WpSessionPrivate WpSessionPrivate;
|
|
|
|
|
struct _WpSessionPrivate
|
2019-09-24 16:34:18 +03:00
|
|
|
{
|
2020-04-01 13:38:39 +03:00
|
|
|
WpObjectManager *endpoints_om;
|
2020-04-01 13:53:45 +03:00
|
|
|
WpObjectManager *links_om;
|
2019-09-24 16:34:18 +03:00
|
|
|
};
|
|
|
|
|
|
2020-11-25 14:02:33 +02:00
|
|
|
static void wp_session_pw_object_mixin_priv_interface_init (
|
|
|
|
|
WpPwObjectMixinPrivInterface * iface);
|
2019-09-24 16:34:18 +03:00
|
|
|
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
/**
|
|
|
|
|
* WpSession:
|
|
|
|
|
*
|
|
|
|
|
* The #WpSession class allows accessing the properties and methods of a
|
|
|
|
|
* PipeWire session object (`struct pw_session` from the session-manager
|
|
|
|
|
* extension).
|
|
|
|
|
*
|
|
|
|
|
* A #WpSession is constructed internally when a new session appears on the
|
|
|
|
|
* PipeWire registry and it is made available through the #WpObjectManager API.
|
|
|
|
|
*/
|
|
|
|
|
G_DEFINE_TYPE_WITH_CODE (WpSession, wp_session, WP_TYPE_GLOBAL_PROXY,
|
|
|
|
|
G_ADD_PRIVATE (WpSession)
|
2020-11-25 14:02:33 +02:00
|
|
|
G_IMPLEMENT_INTERFACE (WP_TYPE_PIPEWIRE_OBJECT,
|
|
|
|
|
wp_pw_object_mixin_object_interface_init)
|
|
|
|
|
G_IMPLEMENT_INTERFACE (WP_TYPE_PW_OBJECT_MIXIN_PRIV,
|
|
|
|
|
wp_session_pw_object_mixin_priv_interface_init))
|
2019-09-24 16:34:18 +03:00
|
|
|
|
|
|
|
|
static void
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
wp_session_init (WpSession * self)
|
2019-09-24 16:34:18 +03:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2020-05-03 19:42:42 +03:00
|
|
|
static void
|
|
|
|
|
wp_session_on_endpoints_om_installed (WpObjectManager *endpoints_om,
|
|
|
|
|
WpSession * self)
|
|
|
|
|
{
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
wp_object_update_features (WP_OBJECT (self), WP_SESSION_FEATURE_ENDPOINTS, 0);
|
2020-05-03 19:42:42 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
wp_session_emit_endpoints_changed (WpObjectManager *endpoints_om,
|
|
|
|
|
WpSession * self)
|
|
|
|
|
{
|
|
|
|
|
g_signal_emit (self, signals[SIGNAL_ENDPOINTS_CHANGED], 0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
wp_session_on_links_om_installed (WpObjectManager *links_om, WpSession * self)
|
|
|
|
|
{
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
wp_object_update_features (WP_OBJECT (self), WP_SESSION_FEATURE_LINKS, 0);
|
2020-05-03 19:42:42 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
wp_session_emit_links_changed (WpObjectManager *links_om, WpSession * self)
|
|
|
|
|
{
|
|
|
|
|
g_signal_emit (self, signals[SIGNAL_LINKS_CHANGED], 0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
wp_session_enable_features_endpoints_links (WpSession * self,
|
|
|
|
|
WpObjectFeatures missing)
|
2020-05-03 19:42:42 +03:00
|
|
|
{
|
|
|
|
|
WpSessionPrivate *priv = wp_session_get_instance_private (self);
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
g_autoptr (WpCore) core = wp_object_get_core (WP_OBJECT (self));
|
|
|
|
|
guint32 bound_id = wp_proxy_get_bound_id (WP_PROXY (self));
|
2020-05-03 19:42:42 +03:00
|
|
|
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
if (missing & WP_SESSION_FEATURE_ENDPOINTS) {
|
2020-05-03 19:42:42 +03:00
|
|
|
wp_debug_object (self, "enabling WP_SESSION_FEATURE_ENDPOINTS, bound_id:%u",
|
|
|
|
|
bound_id);
|
|
|
|
|
|
|
|
|
|
priv->endpoints_om = wp_object_manager_new ();
|
|
|
|
|
/* proxy endpoint -> check for session.id in global properties */
|
2020-05-14 16:24:34 +03:00
|
|
|
wp_object_manager_add_interest (priv->endpoints_om,
|
2020-05-03 19:42:42 +03:00
|
|
|
WP_TYPE_ENDPOINT,
|
|
|
|
|
WP_CONSTRAINT_TYPE_PW_GLOBAL_PROPERTY, PW_KEY_SESSION_ID, "=u", bound_id,
|
|
|
|
|
NULL);
|
|
|
|
|
/* impl endpoint -> check for session.id in standard properties */
|
2020-05-14 16:24:34 +03:00
|
|
|
wp_object_manager_add_interest (priv->endpoints_om,
|
2020-05-03 19:42:42 +03:00
|
|
|
WP_TYPE_IMPL_ENDPOINT,
|
|
|
|
|
WP_CONSTRAINT_TYPE_PW_PROPERTY, PW_KEY_SESSION_ID, "=u", bound_id,
|
|
|
|
|
NULL);
|
|
|
|
|
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
wp_object_manager_request_object_features (priv->endpoints_om,
|
|
|
|
|
WP_TYPE_ENDPOINT, WP_OBJECT_FEATURES_ALL);
|
2020-05-03 19:42:42 +03:00
|
|
|
|
|
|
|
|
g_signal_connect_object (priv->endpoints_om, "installed",
|
|
|
|
|
G_CALLBACK (wp_session_on_endpoints_om_installed), self, 0);
|
|
|
|
|
g_signal_connect_object (priv->endpoints_om, "objects-changed",
|
|
|
|
|
G_CALLBACK (wp_session_emit_endpoints_changed), self, 0);
|
|
|
|
|
|
|
|
|
|
wp_core_install_object_manager (core, priv->endpoints_om);
|
|
|
|
|
}
|
|
|
|
|
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
if (missing & WP_SESSION_FEATURE_LINKS) {
|
2020-05-03 19:42:42 +03:00
|
|
|
wp_debug_object (self, "enabling WP_SESSION_FEATURE_LINKS, bound_id:%u",
|
|
|
|
|
bound_id);
|
|
|
|
|
|
|
|
|
|
priv->links_om = wp_object_manager_new ();
|
|
|
|
|
/* proxy link -> check for session.id in global properties */
|
2020-05-14 16:24:34 +03:00
|
|
|
wp_object_manager_add_interest (priv->links_om,
|
2020-05-03 19:42:42 +03:00
|
|
|
WP_TYPE_ENDPOINT_LINK,
|
|
|
|
|
WP_CONSTRAINT_TYPE_PW_GLOBAL_PROPERTY, PW_KEY_SESSION_ID, "=u", bound_id,
|
|
|
|
|
NULL);
|
|
|
|
|
/* impl link -> check for session.id in standard properties */
|
2020-05-14 16:24:34 +03:00
|
|
|
wp_object_manager_add_interest (priv->links_om,
|
2020-05-03 19:42:42 +03:00
|
|
|
WP_TYPE_IMPL_ENDPOINT_LINK,
|
|
|
|
|
WP_CONSTRAINT_TYPE_PW_PROPERTY, PW_KEY_SESSION_ID, "=u", bound_id,
|
|
|
|
|
NULL);
|
|
|
|
|
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
wp_object_manager_request_object_features (priv->links_om,
|
|
|
|
|
WP_TYPE_ENDPOINT_LINK, WP_OBJECT_FEATURES_ALL);
|
2020-05-03 19:42:42 +03:00
|
|
|
|
|
|
|
|
g_signal_connect_object (priv->links_om, "installed",
|
|
|
|
|
G_CALLBACK (wp_session_on_links_om_installed), self, 0);
|
|
|
|
|
g_signal_connect_object (priv->links_om, "objects-changed",
|
|
|
|
|
G_CALLBACK (wp_session_emit_links_changed), self, 0);
|
|
|
|
|
|
|
|
|
|
wp_core_install_object_manager (core, priv->links_om);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
static WpObjectFeatures
|
|
|
|
|
wp_session_get_supported_features (WpObject * object)
|
2019-09-24 16:34:18 +03:00
|
|
|
{
|
2020-11-25 14:02:33 +02:00
|
|
|
return wp_pw_object_mixin_get_supported_features(object)
|
|
|
|
|
| WP_SESSION_FEATURE_ENDPOINTS
|
|
|
|
|
| WP_SESSION_FEATURE_LINKS;
|
2020-01-22 10:34:56 +02:00
|
|
|
}
|
2019-09-24 16:34:18 +03:00
|
|
|
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
enum {
|
2020-11-25 14:02:33 +02:00
|
|
|
STEP_CHILDREN = WP_PW_OBJECT_MIXIN_STEP_CUSTOM_START,
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
};
|
2020-01-22 10:34:56 +02:00
|
|
|
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
static void
|
|
|
|
|
wp_session_activate_execute_step (WpObject * object,
|
|
|
|
|
WpFeatureActivationTransition * transition, guint step,
|
|
|
|
|
WpObjectFeatures missing)
|
|
|
|
|
{
|
|
|
|
|
switch (step) {
|
2020-11-25 14:02:33 +02:00
|
|
|
case WP_PW_OBJECT_MIXIN_STEP_BIND:
|
|
|
|
|
case WP_TRANSITION_STEP_ERROR:
|
|
|
|
|
/* base class can handle BIND and ERROR */
|
|
|
|
|
WP_OBJECT_CLASS (wp_session_parent_class)->
|
|
|
|
|
activate_execute_step (object, transition, step, missing);
|
|
|
|
|
break;
|
|
|
|
|
case WP_PW_OBJECT_MIXIN_STEP_WAIT_INFO:
|
|
|
|
|
/* just wait, info will be emitted anyway after binding */
|
|
|
|
|
break;
|
|
|
|
|
case WP_PW_OBJECT_MIXIN_STEP_CACHE_PARAMS:
|
|
|
|
|
wp_pw_object_mixin_cache_params (object, missing);
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
break;
|
|
|
|
|
case STEP_CHILDREN:
|
|
|
|
|
wp_session_enable_features_endpoints_links (WP_SESSION (object),
|
|
|
|
|
missing);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
2020-11-25 14:02:33 +02:00
|
|
|
g_assert_not_reached ();
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
}
|
2020-01-22 10:34:56 +02:00
|
|
|
}
|
|
|
|
|
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
static void
|
|
|
|
|
wp_session_deactivate (WpObject * object, WpObjectFeatures features)
|
2020-01-22 10:34:56 +02:00
|
|
|
{
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
WpSession *self = WP_SESSION (object);
|
|
|
|
|
WpSessionPrivate *priv = wp_session_get_instance_private (self);
|
|
|
|
|
|
2020-11-25 14:02:33 +02:00
|
|
|
wp_pw_object_mixin_deactivate (object, features);
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
|
|
|
|
|
if (features & WP_SESSION_FEATURE_ENDPOINTS) {
|
|
|
|
|
g_clear_object (&priv->endpoints_om);
|
|
|
|
|
wp_object_update_features (object, 0, WP_SESSION_FEATURE_ENDPOINTS);
|
|
|
|
|
}
|
|
|
|
|
if (features & WP_SESSION_FEATURE_LINKS) {
|
|
|
|
|
g_clear_object (&priv->links_om);
|
|
|
|
|
wp_object_update_features (object, 0, WP_SESSION_FEATURE_LINKS);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
WP_OBJECT_CLASS (wp_session_parent_class)->deactivate (object, features);
|
2019-09-24 16:34:18 +03:00
|
|
|
}
|
|
|
|
|
|
2020-01-22 10:34:56 +02:00
|
|
|
static const struct pw_session_events session_events = {
|
|
|
|
|
PW_VERSION_SESSION_EVENTS,
|
2020-11-25 14:02:33 +02:00
|
|
|
.info = (HandleEventInfoFunc(session)) wp_pw_object_mixin_handle_event_info,
|
|
|
|
|
.param = wp_pw_object_mixin_handle_event_param,
|
2020-01-22 10:34:56 +02:00
|
|
|
};
|
|
|
|
|
|
2019-09-24 16:34:18 +03:00
|
|
|
static void
|
2020-02-11 16:43:10 +02:00
|
|
|
wp_session_pw_proxy_created (WpProxy * proxy, struct pw_proxy * pw_proxy)
|
2019-09-24 16:34:18 +03:00
|
|
|
{
|
2020-11-25 14:02:33 +02:00
|
|
|
wp_pw_object_mixin_handle_pw_proxy_created (proxy, pw_proxy,
|
|
|
|
|
session, &session_events);
|
2020-01-22 10:34:56 +02:00
|
|
|
}
|
|
|
|
|
|
2020-04-01 13:38:39 +03:00
|
|
|
static void
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
wp_session_pw_proxy_destroyed (WpProxy * proxy)
|
2019-09-24 16:34:18 +03:00
|
|
|
{
|
2020-05-03 19:42:42 +03:00
|
|
|
WpSession *self = WP_SESSION (proxy);
|
|
|
|
|
WpSessionPrivate *priv = wp_session_get_instance_private (self);
|
2020-04-01 13:53:45 +03:00
|
|
|
|
2020-11-25 14:02:33 +02:00
|
|
|
wp_pw_object_mixin_handle_pw_proxy_destroyed (proxy);
|
|
|
|
|
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
g_clear_object (&priv->endpoints_om);
|
|
|
|
|
g_clear_object (&priv->links_om);
|
|
|
|
|
wp_object_update_features (WP_OBJECT (self), 0,
|
|
|
|
|
WP_SESSION_FEATURE_ENDPOINTS |
|
|
|
|
|
WP_SESSION_FEATURE_LINKS);
|
2020-05-29 09:30:36 +03:00
|
|
|
}
|
|
|
|
|
|
2019-09-24 16:34:18 +03:00
|
|
|
static void
|
2020-02-11 16:43:10 +02:00
|
|
|
wp_session_class_init (WpSessionClass * klass)
|
2019-09-24 16:34:18 +03:00
|
|
|
{
|
|
|
|
|
GObjectClass *object_class = (GObjectClass *) klass;
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
WpObjectClass *wpobject_class = (WpObjectClass *) klass;
|
2019-09-24 16:34:18 +03:00
|
|
|
WpProxyClass *proxy_class = (WpProxyClass *) klass;
|
|
|
|
|
|
2020-11-25 14:02:33 +02:00
|
|
|
object_class->get_property = wp_pw_object_mixin_get_property;
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
|
|
|
|
|
wpobject_class->get_supported_features = wp_session_get_supported_features;
|
2020-11-25 14:02:33 +02:00
|
|
|
wpobject_class->activate_get_next_step =
|
|
|
|
|
wp_pw_object_mixin_activate_get_next_step;
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
wpobject_class->activate_execute_step = wp_session_activate_execute_step;
|
|
|
|
|
wpobject_class->deactivate = wp_session_deactivate;
|
2019-09-24 16:34:18 +03:00
|
|
|
|
2020-01-30 17:41:25 +02:00
|
|
|
proxy_class->pw_iface_type = PW_TYPE_INTERFACE_Session;
|
|
|
|
|
proxy_class->pw_iface_version = PW_VERSION_SESSION;
|
2020-02-11 16:43:10 +02:00
|
|
|
proxy_class->pw_proxy_created = wp_session_pw_proxy_created;
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
proxy_class->pw_proxy_destroyed = wp_session_pw_proxy_destroyed;
|
|
|
|
|
|
2020-11-25 14:02:33 +02:00
|
|
|
wp_pw_object_mixin_class_override_properties (object_class);
|
2020-02-11 16:43:10 +02:00
|
|
|
|
2020-05-03 19:42:42 +03:00
|
|
|
/**
|
|
|
|
|
* WpSession::endpoints-changed:
|
|
|
|
|
* @self: the session
|
|
|
|
|
*
|
|
|
|
|
* Emitted when the sessions's endpoints change. This is only emitted
|
|
|
|
|
* when %WP_SESSION_FEATURE_ENDPOINTS is enabled.
|
|
|
|
|
*/
|
|
|
|
|
signals[SIGNAL_ENDPOINTS_CHANGED] = g_signal_new (
|
|
|
|
|
"endpoints-changed", G_TYPE_FROM_CLASS (klass),
|
|
|
|
|
G_SIGNAL_RUN_LAST, 0, NULL, NULL, NULL, G_TYPE_NONE, 0);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* WpSession::links-changed:
|
|
|
|
|
* @self: the session
|
|
|
|
|
*
|
|
|
|
|
* Emitted when the session's links change. This is only emitted
|
|
|
|
|
* when %WP_SESSION_FEATURE_LINKS is enabled.
|
|
|
|
|
*/
|
|
|
|
|
signals[SIGNAL_LINKS_CHANGED] = g_signal_new (
|
|
|
|
|
"links-changed", G_TYPE_FROM_CLASS (klass),
|
|
|
|
|
G_SIGNAL_RUN_LAST, 0, NULL, NULL, NULL, G_TYPE_NONE, 0);
|
2019-09-24 16:34:18 +03:00
|
|
|
}
|
|
|
|
|
|
2020-11-25 14:02:33 +02:00
|
|
|
static gint
|
|
|
|
|
wp_session_enum_params (gpointer instance, guint32 id,
|
|
|
|
|
guint32 start, guint32 num, WpSpaPod *filter)
|
2020-05-16 12:53:37 +03:00
|
|
|
{
|
2020-11-25 14:02:33 +02:00
|
|
|
WpPwObjectMixinData *d = wp_pw_object_mixin_get_data (instance);
|
|
|
|
|
return pw_session_enum_params (d->iface, 0, id, start, num,
|
|
|
|
|
filter ? wp_spa_pod_get_spa_pod (filter) : NULL);
|
2020-05-16 12:53:37 +03:00
|
|
|
}
|
|
|
|
|
|
2020-11-25 14:02:33 +02:00
|
|
|
static gint
|
|
|
|
|
wp_session_set_param (gpointer instance, guint32 id, guint32 flags,
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
WpSpaPod * param)
|
|
|
|
|
{
|
2020-11-25 14:02:33 +02:00
|
|
|
WpPwObjectMixinData *d = wp_pw_object_mixin_get_data (instance);
|
|
|
|
|
return pw_session_set_param (d->iface, id, flags,
|
|
|
|
|
wp_spa_pod_get_spa_pod (param));
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2020-11-25 14:02:33 +02:00
|
|
|
wp_session_pw_object_mixin_priv_interface_init (
|
|
|
|
|
WpPwObjectMixinPrivInterface * iface)
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
{
|
2020-11-25 14:02:33 +02:00
|
|
|
wp_pw_object_mixin_priv_interface_info_init (iface, session, SESSION);
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
iface->enum_params = wp_session_enum_params;
|
|
|
|
|
iface->set_param = wp_session_set_param;
|
2019-09-24 16:34:18 +03:00
|
|
|
}
|
|
|
|
|
|
2020-02-17 15:39:19 +02:00
|
|
|
/**
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
* wp_session_get_name:
|
2020-02-17 15:39:19 +02:00
|
|
|
* @self: the session
|
|
|
|
|
*
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
* Requires %WP_PIPEWIRE_OBJECT_FEATURE_INFO
|
|
|
|
|
*
|
|
|
|
|
* Returns: (transfer none): the (unique) name of the session
|
2020-02-17 15:39:19 +02:00
|
|
|
*/
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
const gchar *
|
|
|
|
|
wp_session_get_name (WpSession * self)
|
2020-02-11 16:43:10 +02:00
|
|
|
{
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
g_return_val_if_fail (WP_IS_SESSION (self), NULL);
|
|
|
|
|
g_return_val_if_fail (wp_object_get_active_features (WP_OBJECT (self)) &
|
|
|
|
|
WP_PIPEWIRE_OBJECT_FEATURE_INFO, NULL);
|
2020-05-25 18:51:23 +03:00
|
|
|
|
2020-11-25 14:02:33 +02:00
|
|
|
return wp_pipewire_object_get_property (WP_PIPEWIRE_OBJECT (self),
|
|
|
|
|
"session.name");
|
2020-02-11 16:43:10 +02:00
|
|
|
}
|
|
|
|
|
|
2020-04-01 13:38:39 +03:00
|
|
|
/**
|
|
|
|
|
* wp_session_get_n_endpoints:
|
|
|
|
|
* @self: the session
|
|
|
|
|
*
|
2020-05-05 12:17:08 +03:00
|
|
|
* Requires %WP_SESSION_FEATURE_ENDPOINTS
|
|
|
|
|
*
|
2020-04-01 13:38:39 +03:00
|
|
|
* Returns: the number of endpoints of this session
|
|
|
|
|
*/
|
|
|
|
|
guint
|
|
|
|
|
wp_session_get_n_endpoints (WpSession * self)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail (WP_IS_SESSION (self), 0);
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
g_return_val_if_fail (wp_object_get_active_features (WP_OBJECT (self)) &
|
2020-04-01 13:38:39 +03:00
|
|
|
WP_SESSION_FEATURE_ENDPOINTS, 0);
|
|
|
|
|
|
|
|
|
|
WpSessionPrivate *priv = wp_session_get_instance_private (self);
|
|
|
|
|
return wp_object_manager_get_n_objects (priv->endpoints_om);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2021-02-05 10:20:33 -05:00
|
|
|
* wp_session_new_endpoints_iterator:
|
2020-04-01 13:38:39 +03:00
|
|
|
* @self: the session
|
|
|
|
|
*
|
2020-05-05 12:17:08 +03:00
|
|
|
* Requires %WP_SESSION_FEATURE_ENDPOINTS
|
|
|
|
|
*
|
|
|
|
|
* Returns: (transfer full): a #WpIterator that iterates over all
|
|
|
|
|
* the endpoints that belong to this session
|
2020-04-01 13:38:39 +03:00
|
|
|
*/
|
2020-05-05 12:17:08 +03:00
|
|
|
WpIterator *
|
2021-02-05 10:20:33 -05:00
|
|
|
wp_session_new_endpoints_iterator (WpSession * self)
|
2020-04-01 13:38:39 +03:00
|
|
|
{
|
|
|
|
|
g_return_val_if_fail (WP_IS_SESSION (self), NULL);
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
g_return_val_if_fail (wp_object_get_active_features (WP_OBJECT (self)) &
|
2020-04-01 13:38:39 +03:00
|
|
|
WP_SESSION_FEATURE_ENDPOINTS, NULL);
|
|
|
|
|
|
|
|
|
|
WpSessionPrivate *priv = wp_session_get_instance_private (self);
|
2021-02-05 10:20:33 -05:00
|
|
|
return wp_object_manager_new_iterator (priv->endpoints_om);
|
2020-04-01 13:38:39 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2021-02-05 10:20:33 -05:00
|
|
|
* wp_session_new_endpoints_filtered_iterator:
|
2020-04-01 13:38:39 +03:00
|
|
|
* @self: the session
|
2020-05-05 12:17:08 +03:00
|
|
|
* @...: a list of constraints, terminated by %NULL
|
|
|
|
|
*
|
|
|
|
|
* Requires %WP_SESSION_FEATURE_ENDPOINTS
|
|
|
|
|
*
|
|
|
|
|
* The constraints specified in the variable arguments must follow the rules
|
|
|
|
|
* documented in wp_object_interest_new().
|
2020-04-01 13:38:39 +03:00
|
|
|
*
|
2020-04-21 13:21:03 +03:00
|
|
|
* Returns: (transfer full): a #WpIterator that iterates over all
|
2020-05-05 12:17:08 +03:00
|
|
|
* the endpoints that belong to this session and match the constraints
|
2020-04-01 13:38:39 +03:00
|
|
|
*/
|
2020-04-21 13:21:03 +03:00
|
|
|
WpIterator *
|
2021-02-05 10:20:33 -05:00
|
|
|
wp_session_new_endpoints_filtered_iterator (WpSession * self, ...)
|
2020-05-05 12:17:08 +03:00
|
|
|
{
|
|
|
|
|
WpObjectInterest *interest;
|
|
|
|
|
va_list args;
|
|
|
|
|
va_start (args, self);
|
|
|
|
|
interest = wp_object_interest_new_valist (WP_TYPE_ENDPOINT, &args);
|
|
|
|
|
va_end (args);
|
2021-02-05 10:20:33 -05:00
|
|
|
return wp_session_new_endpoints_filtered_iterator_full (self, interest);
|
2020-05-05 12:17:08 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2021-02-05 10:20:33 -05:00
|
|
|
* wp_session_new_endpoints_filtered_iterator_full: (rename-to wp_session_new_endpoints_filtered_iterator)
|
2020-05-05 12:17:08 +03:00
|
|
|
* @self: the session
|
|
|
|
|
* @interest: (transfer full): the interest
|
|
|
|
|
*
|
|
|
|
|
* Requires %WP_SESSION_FEATURE_ENDPOINTS
|
|
|
|
|
*
|
|
|
|
|
* Returns: (transfer full): a #WpIterator that iterates over all
|
|
|
|
|
* the endpoints that belong to this session and match the @interest
|
|
|
|
|
*/
|
|
|
|
|
WpIterator *
|
2021-02-05 10:20:33 -05:00
|
|
|
wp_session_new_endpoints_filtered_iterator_full (WpSession * self,
|
2020-05-05 12:17:08 +03:00
|
|
|
WpObjectInterest * interest)
|
2020-04-01 13:38:39 +03:00
|
|
|
{
|
|
|
|
|
g_return_val_if_fail (WP_IS_SESSION (self), NULL);
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
g_return_val_if_fail (wp_object_get_active_features (WP_OBJECT (self)) &
|
2020-04-01 13:38:39 +03:00
|
|
|
WP_SESSION_FEATURE_ENDPOINTS, NULL);
|
|
|
|
|
|
|
|
|
|
WpSessionPrivate *priv = wp_session_get_instance_private (self);
|
2021-02-05 10:20:33 -05:00
|
|
|
return wp_object_manager_new_filtered_iterator_full (priv->endpoints_om,
|
|
|
|
|
interest);
|
2020-05-05 12:17:08 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* wp_session_lookup_endpoint:
|
|
|
|
|
* @self: the session
|
|
|
|
|
* @...: a list of constraints, terminated by %NULL
|
|
|
|
|
*
|
|
|
|
|
* Requires %WP_SESSION_FEATURE_ENDPOINTS
|
|
|
|
|
*
|
|
|
|
|
* The constraints specified in the variable arguments must follow the rules
|
|
|
|
|
* documented in wp_object_interest_new().
|
|
|
|
|
*
|
|
|
|
|
* Returns: (transfer full) (nullable): the first endpoint that matches the
|
|
|
|
|
* constraints, or %NULL if there is no such endpoint
|
|
|
|
|
*/
|
|
|
|
|
WpEndpoint *
|
|
|
|
|
wp_session_lookup_endpoint (WpSession * self, ...)
|
|
|
|
|
{
|
|
|
|
|
WpObjectInterest *interest;
|
|
|
|
|
va_list args;
|
|
|
|
|
va_start (args, self);
|
|
|
|
|
interest = wp_object_interest_new_valist (WP_TYPE_ENDPOINT, &args);
|
|
|
|
|
va_end (args);
|
|
|
|
|
return wp_session_lookup_endpoint_full (self, interest);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* wp_session_lookup_endpoint_full: (rename-to wp_session_lookup_endpoint)
|
|
|
|
|
* @self: the session
|
|
|
|
|
* @interest: (transfer full): the interest
|
|
|
|
|
*
|
|
|
|
|
* Requires %WP_SESSION_FEATURE_ENDPOINTS
|
|
|
|
|
*
|
|
|
|
|
* Returns: (transfer full) (nullable): the first endpoint that matches the
|
|
|
|
|
* @interest, or %NULL if there is no such endpoint
|
|
|
|
|
*/
|
|
|
|
|
WpEndpoint *
|
|
|
|
|
wp_session_lookup_endpoint_full (WpSession * self, WpObjectInterest * interest)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail (WP_IS_SESSION (self), NULL);
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
g_return_val_if_fail (wp_object_get_active_features (WP_OBJECT (self)) &
|
2020-05-05 12:17:08 +03:00
|
|
|
WP_SESSION_FEATURE_ENDPOINTS, NULL);
|
|
|
|
|
|
|
|
|
|
WpSessionPrivate *priv = wp_session_get_instance_private (self);
|
|
|
|
|
return (WpEndpoint *)
|
|
|
|
|
wp_object_manager_lookup_full (priv->endpoints_om, interest);
|
2020-04-01 13:38:39 +03:00
|
|
|
}
|
|
|
|
|
|
2020-04-01 13:53:45 +03:00
|
|
|
/**
|
|
|
|
|
* wp_session_get_n_links:
|
|
|
|
|
* @self: the session
|
|
|
|
|
*
|
2020-05-05 12:17:08 +03:00
|
|
|
* Requires %WP_SESSION_FEATURE_LINKS
|
|
|
|
|
*
|
2020-04-01 13:53:45 +03:00
|
|
|
* Returns: the number of endpoint links of this session
|
|
|
|
|
*/
|
|
|
|
|
guint
|
|
|
|
|
wp_session_get_n_links (WpSession * self)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail (WP_IS_SESSION (self), 0);
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
g_return_val_if_fail (wp_object_get_active_features (WP_OBJECT (self)) &
|
2020-04-01 13:53:45 +03:00
|
|
|
WP_SESSION_FEATURE_LINKS, 0);
|
|
|
|
|
|
|
|
|
|
WpSessionPrivate *priv = wp_session_get_instance_private (self);
|
|
|
|
|
return wp_object_manager_get_n_objects (priv->links_om);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2021-02-05 10:20:33 -05:00
|
|
|
* wp_session_new_links_iterator:
|
2020-04-01 13:53:45 +03:00
|
|
|
* @self: the session
|
|
|
|
|
*
|
2020-05-05 12:17:08 +03:00
|
|
|
* Requires %WP_SESSION_FEATURE_LINKS
|
|
|
|
|
*
|
|
|
|
|
* Returns: (transfer full): a #WpIterator that iterates over all
|
|
|
|
|
* the endpoint links that belong to this session
|
2020-04-01 13:53:45 +03:00
|
|
|
*/
|
2020-05-05 12:17:08 +03:00
|
|
|
WpIterator *
|
2021-02-05 10:20:33 -05:00
|
|
|
wp_session_new_links_iterator (WpSession * self)
|
2020-04-01 13:53:45 +03:00
|
|
|
{
|
|
|
|
|
g_return_val_if_fail (WP_IS_SESSION (self), NULL);
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
g_return_val_if_fail (wp_object_get_active_features (WP_OBJECT (self)) &
|
2020-04-01 13:53:45 +03:00
|
|
|
WP_SESSION_FEATURE_LINKS, NULL);
|
|
|
|
|
|
|
|
|
|
WpSessionPrivate *priv = wp_session_get_instance_private (self);
|
2021-02-05 10:20:33 -05:00
|
|
|
return wp_object_manager_new_iterator (priv->links_om);
|
2020-04-01 13:53:45 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2021-02-05 10:20:33 -05:00
|
|
|
* wp_session_new_links_filtered_iterator:
|
2020-04-01 13:53:45 +03:00
|
|
|
* @self: the session
|
2020-05-05 12:17:08 +03:00
|
|
|
* @...: a list of constraints, terminated by %NULL
|
|
|
|
|
*
|
|
|
|
|
* Requires %WP_SESSION_FEATURE_LINKS
|
|
|
|
|
*
|
|
|
|
|
* The constraints specified in the variable arguments must follow the rules
|
|
|
|
|
* documented in wp_object_interest_new().
|
2020-04-01 13:53:45 +03:00
|
|
|
*
|
2020-04-21 13:21:03 +03:00
|
|
|
* Returns: (transfer full): a #WpIterator that iterates over all
|
2020-05-05 12:17:08 +03:00
|
|
|
* the links that belong to this session and match the constraints
|
2020-04-01 13:53:45 +03:00
|
|
|
*/
|
2020-04-21 13:21:03 +03:00
|
|
|
WpIterator *
|
2021-02-05 10:20:33 -05:00
|
|
|
wp_session_new_links_filtered_iterator (WpSession * self, ...)
|
2020-05-05 12:17:08 +03:00
|
|
|
{
|
|
|
|
|
WpObjectInterest *interest;
|
|
|
|
|
va_list args;
|
|
|
|
|
va_start (args, self);
|
|
|
|
|
interest = wp_object_interest_new_valist (WP_TYPE_ENDPOINT_LINK, &args);
|
|
|
|
|
va_end (args);
|
2021-02-05 10:20:33 -05:00
|
|
|
return wp_session_new_links_filtered_iterator_full (self, interest);
|
2020-05-05 12:17:08 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2021-02-05 10:20:33 -05:00
|
|
|
* wp_session_new_links_filtered_iterator_full: (rename-to wp_session_new_links_filtered_iterator)
|
2020-05-05 12:17:08 +03:00
|
|
|
* @self: the session
|
|
|
|
|
* @interest: (transfer full): the interest
|
|
|
|
|
*
|
|
|
|
|
* Requires %WP_SESSION_FEATURE_LINKS
|
|
|
|
|
*
|
|
|
|
|
* Returns: (transfer full): a #WpIterator that iterates over all
|
|
|
|
|
* the links that belong to this session and match the @interest
|
|
|
|
|
*/
|
|
|
|
|
WpIterator *
|
2021-02-05 10:20:33 -05:00
|
|
|
wp_session_new_links_filtered_iterator_full (WpSession * self,
|
2020-05-05 12:17:08 +03:00
|
|
|
WpObjectInterest * interest)
|
2020-04-01 13:53:45 +03:00
|
|
|
{
|
|
|
|
|
g_return_val_if_fail (WP_IS_SESSION (self), NULL);
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
g_return_val_if_fail (wp_object_get_active_features (WP_OBJECT (self)) &
|
2020-04-01 13:53:45 +03:00
|
|
|
WP_SESSION_FEATURE_LINKS, NULL);
|
|
|
|
|
|
|
|
|
|
WpSessionPrivate *priv = wp_session_get_instance_private (self);
|
2021-02-05 10:20:33 -05:00
|
|
|
return wp_object_manager_new_filtered_iterator_full (priv->links_om,
|
|
|
|
|
interest);
|
2020-05-05 12:17:08 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* wp_session_lookup_link:
|
|
|
|
|
* @self: the session
|
|
|
|
|
* @...: a list of constraints, terminated by %NULL
|
|
|
|
|
*
|
|
|
|
|
* Requires %WP_SESSION_FEATURE_LINKS
|
|
|
|
|
*
|
|
|
|
|
* The constraints specified in the variable arguments must follow the rules
|
|
|
|
|
* documented in wp_object_interest_new().
|
|
|
|
|
*
|
|
|
|
|
* Returns: (transfer full) (nullable): the first link that matches the
|
|
|
|
|
* constraints, or %NULL if there is no such link
|
|
|
|
|
*/
|
|
|
|
|
WpEndpointLink *
|
|
|
|
|
wp_session_lookup_link (WpSession * self, ...)
|
|
|
|
|
{
|
|
|
|
|
WpObjectInterest *interest;
|
|
|
|
|
va_list args;
|
|
|
|
|
va_start (args, self);
|
|
|
|
|
interest = wp_object_interest_new_valist (WP_TYPE_ENDPOINT_LINK, &args);
|
|
|
|
|
va_end (args);
|
|
|
|
|
return wp_session_lookup_link_full (self, interest);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* wp_session_lookup_link_full: (rename-to wp_session_lookup_link)
|
|
|
|
|
* @self: the session
|
|
|
|
|
* @interest: (transfer full): the interest
|
|
|
|
|
*
|
|
|
|
|
* Requires %WP_SESSION_FEATURE_LINKS
|
|
|
|
|
*
|
|
|
|
|
* Returns: (transfer full) (nullable): the first link that matches the
|
|
|
|
|
* @interest, or %NULL if there is no such link
|
|
|
|
|
*/
|
|
|
|
|
WpEndpointLink *
|
|
|
|
|
wp_session_lookup_link_full (WpSession * self, WpObjectInterest * interest)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail (WP_IS_SESSION (self), NULL);
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
g_return_val_if_fail (wp_object_get_active_features (WP_OBJECT (self)) &
|
2020-05-05 12:17:08 +03:00
|
|
|
WP_SESSION_FEATURE_LINKS, NULL);
|
|
|
|
|
|
|
|
|
|
WpSessionPrivate *priv = wp_session_get_instance_private (self);
|
|
|
|
|
return (WpEndpointLink *)
|
|
|
|
|
wp_object_manager_lookup_full (priv->links_om, interest);
|
2020-04-01 13:53:45 +03:00
|
|
|
}
|
|
|
|
|
|
2020-02-11 16:43:10 +02:00
|
|
|
/* WpImplSession */
|
2019-09-24 16:34:18 +03:00
|
|
|
|
2020-04-01 13:06:18 +03:00
|
|
|
typedef struct _WpImplSession WpImplSession;
|
|
|
|
|
struct _WpImplSession
|
2019-09-24 16:34:18 +03:00
|
|
|
{
|
2020-04-01 13:06:18 +03:00
|
|
|
WpSession parent;
|
|
|
|
|
|
|
|
|
|
struct spa_interface iface;
|
2019-09-24 16:34:18 +03:00
|
|
|
struct pw_session_info info;
|
|
|
|
|
};
|
|
|
|
|
|
2020-11-25 14:02:33 +02:00
|
|
|
|
|
|
|
|
static void wp_session_impl_pw_object_mixin_priv_interface_init (
|
|
|
|
|
WpPwObjectMixinPrivInterface * iface);
|
|
|
|
|
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
/**
|
|
|
|
|
* WpImplSession:
|
|
|
|
|
*
|
|
|
|
|
* A #WpImplSession allows implementing a session and exporting it to PipeWire.
|
|
|
|
|
* To export a #WpImplSession, activate %WP_PROXY_FEATURE_BOUND.
|
|
|
|
|
*/
|
2020-11-25 14:02:33 +02:00
|
|
|
G_DEFINE_TYPE_WITH_CODE (WpImplSession, wp_impl_session, WP_TYPE_SESSION,
|
|
|
|
|
G_IMPLEMENT_INTERFACE (WP_TYPE_PW_OBJECT_MIXIN_PRIV,
|
|
|
|
|
wp_session_impl_pw_object_mixin_priv_interface_init))
|
2019-09-24 16:34:18 +03:00
|
|
|
|
2020-04-01 13:06:18 +03:00
|
|
|
static const struct pw_session_methods impl_session = {
|
|
|
|
|
PW_VERSION_SESSION_METHODS,
|
2020-11-25 14:02:33 +02:00
|
|
|
.add_listener =
|
|
|
|
|
(ImplAddListenerFunc(session)) wp_pw_object_mixin_impl_add_listener,
|
|
|
|
|
.subscribe_params = wp_pw_object_mixin_impl_subscribe_params,
|
|
|
|
|
.enum_params = wp_pw_object_mixin_impl_enum_params,
|
|
|
|
|
.set_param = wp_pw_object_mixin_impl_set_param,
|
2019-09-24 16:34:18 +03:00
|
|
|
};
|
|
|
|
|
|
2020-04-01 13:06:18 +03:00
|
|
|
static void
|
|
|
|
|
wp_impl_session_init (WpImplSession * self)
|
|
|
|
|
{
|
2020-11-25 14:02:33 +02:00
|
|
|
WpPwObjectMixinData *d = wp_pw_object_mixin_get_data (self);
|
2020-04-01 13:06:18 +03:00
|
|
|
|
|
|
|
|
self->iface = SPA_INTERFACE_INIT (
|
|
|
|
|
PW_TYPE_INTERFACE_Session,
|
|
|
|
|
PW_VERSION_SESSION,
|
|
|
|
|
&impl_session, self);
|
|
|
|
|
|
2020-11-25 14:02:33 +02:00
|
|
|
d->info = &self->info;
|
|
|
|
|
d->iface = &self->iface;
|
2020-04-01 13:06:18 +03:00
|
|
|
|
|
|
|
|
/* prepare INFO */
|
2020-11-25 14:02:33 +02:00
|
|
|
d->properties = wp_properties_new_empty ();
|
2020-04-01 13:06:18 +03:00
|
|
|
self->info.version = PW_VERSION_SESSION_INFO;
|
2020-11-25 14:02:33 +02:00
|
|
|
self->info.props = (struct spa_dict *) wp_properties_peek_dict (d->properties);
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
self->info.params = NULL;
|
|
|
|
|
self->info.n_params = 0;
|
2020-11-25 14:02:33 +02:00
|
|
|
|
|
|
|
|
wp_object_update_features (WP_OBJECT (self),
|
|
|
|
|
WP_PIPEWIRE_OBJECT_FEATURE_INFO, 0);
|
2020-04-01 13:06:18 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2020-11-25 14:02:33 +02:00
|
|
|
wp_impl_session_dispose (GObject * object)
|
2020-04-01 13:06:18 +03:00
|
|
|
{
|
2020-11-25 14:02:33 +02:00
|
|
|
wp_object_update_features (WP_OBJECT (object), 0,
|
|
|
|
|
WP_PIPEWIRE_OBJECT_FEATURE_INFO);
|
2020-04-01 13:06:18 +03:00
|
|
|
|
2020-11-25 14:02:33 +02:00
|
|
|
G_OBJECT_CLASS (wp_impl_session_parent_class)->dispose (object);
|
2020-04-01 13:06:18 +03:00
|
|
|
}
|
|
|
|
|
|
2019-09-24 16:34:18 +03:00
|
|
|
static void
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
wp_impl_session_activate_execute_step (WpObject * object,
|
|
|
|
|
WpFeatureActivationTransition * transition, guint step,
|
|
|
|
|
WpObjectFeatures missing)
|
2020-02-11 16:43:10 +02:00
|
|
|
{
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
WpImplSession *self = WP_IMPL_SESSION (object);
|
2020-11-25 14:02:33 +02:00
|
|
|
WpPwObjectMixinData *d = wp_pw_object_mixin_get_data (self);
|
2020-02-11 16:43:10 +02:00
|
|
|
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
switch (step) {
|
2020-11-25 14:02:33 +02:00
|
|
|
case WP_PW_OBJECT_MIXIN_STEP_BIND: {
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
g_autoptr (WpCore) core = wp_object_get_core (object);
|
2020-02-11 16:43:10 +02:00
|
|
|
struct pw_core *pw_core = wp_core_get_pw_core (core);
|
|
|
|
|
|
|
|
|
|
/* no pw_core -> we are not connected */
|
|
|
|
|
if (!pw_core) {
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
wp_transition_return_error (WP_TRANSITION (transition), g_error_new (
|
|
|
|
|
WP_DOMAIN_LIBRARY, WP_LIBRARY_ERROR_OPERATION_FAILED,
|
|
|
|
|
"The WirePlumber core is not connected; "
|
|
|
|
|
"object cannot be exported to PipeWire"));
|
2020-02-11 16:43:10 +02:00
|
|
|
return;
|
|
|
|
|
}
|
2019-09-24 16:34:18 +03:00
|
|
|
|
2020-02-11 16:43:10 +02:00
|
|
|
/* make sure these props are not present; they are added by the server */
|
2020-11-25 14:02:33 +02:00
|
|
|
wp_properties_set (d->properties, PW_KEY_OBJECT_ID, NULL);
|
|
|
|
|
wp_properties_set (d->properties, PW_KEY_CLIENT_ID, NULL);
|
|
|
|
|
wp_properties_set (d->properties, PW_KEY_FACTORY_ID, NULL);
|
2020-04-01 13:06:18 +03:00
|
|
|
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
wp_proxy_set_pw_proxy (WP_PROXY (self), pw_core_export (pw_core,
|
2020-04-01 13:06:18 +03:00
|
|
|
PW_TYPE_INTERFACE_Session,
|
2020-11-25 14:02:33 +02:00
|
|
|
wp_properties_peek_dict (d->properties),
|
|
|
|
|
&self->iface, 0));
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
default:
|
|
|
|
|
WP_OBJECT_CLASS (wp_impl_session_parent_class)->
|
|
|
|
|
activate_execute_step (object, transition, step, missing);
|
|
|
|
|
break;
|
2020-04-01 13:53:45 +03:00
|
|
|
}
|
2019-09-24 16:34:18 +03:00
|
|
|
}
|
|
|
|
|
|
2020-05-29 09:30:36 +03:00
|
|
|
static void
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
wp_impl_session_pw_proxy_destroyed (WpProxy * proxy)
|
2020-05-29 09:30:36 +03:00
|
|
|
{
|
|
|
|
|
WpImplSession *self = WP_IMPL_SESSION (proxy);
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
WpSessionPrivate *priv = wp_session_get_instance_private (WP_SESSION (self));
|
2020-05-29 09:30:36 +03:00
|
|
|
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
g_clear_object (&priv->endpoints_om);
|
|
|
|
|
g_clear_object (&priv->links_om);
|
|
|
|
|
wp_object_update_features (WP_OBJECT (self), 0,
|
|
|
|
|
WP_SESSION_FEATURE_ENDPOINTS |
|
|
|
|
|
WP_SESSION_FEATURE_LINKS);
|
2020-05-29 09:30:36 +03:00
|
|
|
}
|
|
|
|
|
|
2019-09-24 16:34:18 +03:00
|
|
|
static void
|
2020-02-11 16:43:10 +02:00
|
|
|
wp_impl_session_class_init (WpImplSessionClass * klass)
|
2019-09-24 16:34:18 +03:00
|
|
|
{
|
|
|
|
|
GObjectClass *object_class = (GObjectClass *) klass;
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
WpObjectClass *wpobject_class = (WpObjectClass *) klass;
|
2020-02-11 16:43:10 +02:00
|
|
|
WpProxyClass *proxy_class = (WpProxyClass *) klass;
|
2019-09-24 16:34:18 +03:00
|
|
|
|
2020-11-25 14:02:33 +02:00
|
|
|
object_class->dispose = wp_impl_session_dispose;
|
2019-09-24 16:34:18 +03:00
|
|
|
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
wpobject_class->activate_execute_step = wp_impl_session_activate_execute_step;
|
|
|
|
|
|
2020-02-11 16:43:10 +02:00
|
|
|
proxy_class->pw_proxy_created = NULL;
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
proxy_class->pw_proxy_destroyed = wp_impl_session_pw_proxy_destroyed;
|
2019-09-24 16:34:18 +03:00
|
|
|
}
|
|
|
|
|
|
2020-11-25 14:02:33 +02:00
|
|
|
#define pw_session_emit(hooks,method,version,...) \
|
|
|
|
|
spa_hook_list_call_simple(hooks, struct pw_session_events, \
|
|
|
|
|
method, version, ##__VA_ARGS__)
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
wp_impl_session_emit_info (struct spa_hook_list * hooks, gconstpointer info)
|
|
|
|
|
{
|
|
|
|
|
pw_session_emit (hooks, info, 0, info);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
wp_impl_session_emit_param (struct spa_hook_list * hooks, int seq,
|
|
|
|
|
guint32 id, guint32 index, guint32 next, const struct spa_pod *param)
|
|
|
|
|
{
|
|
|
|
|
pw_session_emit (hooks, param, 0, seq, id, index, next, param);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
wp_session_impl_pw_object_mixin_priv_interface_init (
|
|
|
|
|
WpPwObjectMixinPrivInterface * iface)
|
|
|
|
|
{
|
|
|
|
|
iface->flags |= WP_PW_OBJECT_MIXIN_PRIV_NO_PARAM_CACHE;
|
|
|
|
|
iface->emit_info = wp_impl_session_emit_info;
|
|
|
|
|
iface->emit_param = wp_impl_session_emit_param;
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-17 15:39:19 +02:00
|
|
|
/**
|
|
|
|
|
* wp_impl_session_new:
|
|
|
|
|
* @core: the #WpCore
|
|
|
|
|
*
|
|
|
|
|
* Returns: (transfer full): the newly constructed session implementation
|
|
|
|
|
*/
|
2020-02-11 16:43:10 +02:00
|
|
|
WpImplSession *
|
|
|
|
|
wp_impl_session_new (WpCore * core)
|
2019-09-24 16:34:18 +03:00
|
|
|
{
|
|
|
|
|
g_return_val_if_fail (WP_IS_CORE (core), NULL);
|
|
|
|
|
|
2020-02-11 16:43:10 +02:00
|
|
|
return g_object_new (WP_TYPE_IMPL_SESSION,
|
2019-09-24 16:34:18 +03:00
|
|
|
"core", core,
|
|
|
|
|
NULL);
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-17 15:39:19 +02:00
|
|
|
/**
|
|
|
|
|
* wp_impl_session_set_property:
|
|
|
|
|
* @self: the session implementation
|
|
|
|
|
* @key: a property key
|
|
|
|
|
* @value: a property value
|
|
|
|
|
*
|
|
|
|
|
* Sets the specified property on the PipeWire properties of the session.
|
|
|
|
|
*
|
|
|
|
|
* If this property is set before exporting the session, then it is also used
|
|
|
|
|
* in the construction process of the session object and appears as a global
|
|
|
|
|
* property.
|
|
|
|
|
*/
|
2019-09-24 16:34:18 +03:00
|
|
|
void
|
2020-02-11 16:43:10 +02:00
|
|
|
wp_impl_session_set_property (WpImplSession * self,
|
2019-09-24 16:34:18 +03:00
|
|
|
const gchar * key, const gchar * value)
|
|
|
|
|
{
|
2020-02-11 16:43:10 +02:00
|
|
|
g_return_if_fail (WP_IS_IMPL_SESSION (self));
|
2019-09-24 16:34:18 +03:00
|
|
|
|
2020-11-25 14:02:33 +02:00
|
|
|
WpPwObjectMixinData *d = wp_pw_object_mixin_get_data (self);
|
|
|
|
|
wp_properties_set (d->properties, key, value);
|
|
|
|
|
wp_pw_object_mixin_notify_info (self, PW_SESSION_CHANGE_MASK_PROPS);
|
2019-09-24 16:34:18 +03:00
|
|
|
}
|
|
|
|
|
|
2020-02-17 15:39:19 +02:00
|
|
|
/**
|
|
|
|
|
* wp_impl_session_update_properties:
|
|
|
|
|
* @self: the session implementation
|
|
|
|
|
* @updates: a set of properties to add or update in the session's properties
|
|
|
|
|
*
|
|
|
|
|
* Adds or updates the values of the PipeWire properties of the session
|
|
|
|
|
* using the properties in @updates as a source.
|
|
|
|
|
*
|
|
|
|
|
* If the properties are set before exporting the session, then they are also
|
|
|
|
|
* used in the construction process of the session object and appear as
|
|
|
|
|
* global properties.
|
|
|
|
|
*/
|
2019-09-24 16:34:18 +03:00
|
|
|
void
|
2020-02-11 16:43:10 +02:00
|
|
|
wp_impl_session_update_properties (WpImplSession * self,
|
2019-09-24 16:34:18 +03:00
|
|
|
WpProperties * updates)
|
|
|
|
|
{
|
2020-02-11 16:43:10 +02:00
|
|
|
g_return_if_fail (WP_IS_IMPL_SESSION (self));
|
2019-09-24 16:34:18 +03:00
|
|
|
|
2020-11-25 14:02:33 +02:00
|
|
|
WpPwObjectMixinData *d = wp_pw_object_mixin_get_data (self);
|
|
|
|
|
wp_properties_update (d->properties, updates);
|
|
|
|
|
wp_pw_object_mixin_notify_info (self, PW_SESSION_CHANGE_MASK_PROPS);
|
2019-09-24 16:34:18 +03:00
|
|
|
}
|