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-02-11 16:43:10 +02:00
|
|
|
#include "error.h"
|
2019-09-24 16:34:18 +03:00
|
|
|
#include "wpenums.h"
|
2020-11-15 20:01:51 +02:00
|
|
|
#include "private/impl-endpoint.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 {
|
|
|
|
|
SIGNAL_DEFAULT_ENDPOINT_CHANGED,
|
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
|
|
|
{
|
|
|
|
|
WpProperties *properties;
|
|
|
|
|
struct pw_session_info *info;
|
2020-04-01 13:06:18 +03:00
|
|
|
struct pw_session *iface;
|
2019-09-24 16:34:18 +03:00
|
|
|
struct spa_hook listener;
|
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
|
|
|
};
|
|
|
|
|
|
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_pipewire_object_interface_init (WpPipewireObjectInterface * 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)
|
|
|
|
|
G_IMPLEMENT_INTERFACE (WP_TYPE_PIPEWIRE_OBJECT, wp_session_pipewire_object_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
|
|
|
{
|
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);
|
2020-02-11 16:43:10 +02: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
|
|
|
return
|
|
|
|
|
WP_PROXY_FEATURE_BOUND |
|
|
|
|
|
WP_SESSION_FEATURE_ENDPOINTS |
|
|
|
|
|
WP_SESSION_FEATURE_LINKS |
|
|
|
|
|
WP_PIPEWIRE_OBJECT_FEATURE_INFO |
|
|
|
|
|
wp_pipewire_object_mixin_param_info_to_features (
|
|
|
|
|
priv->info ? priv->info->params : NULL,
|
|
|
|
|
priv->info ? priv->info->n_params : 0);
|
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 {
|
|
|
|
|
STEP_CHILDREN = WP_PIPEWIRE_OBJECT_MIXIN_STEP_CUSTOM_START,
|
|
|
|
|
};
|
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 guint
|
|
|
|
|
wp_session_activate_get_next_step (WpObject * object,
|
|
|
|
|
WpFeatureActivationTransition * transition, guint step,
|
|
|
|
|
WpObjectFeatures missing)
|
2020-05-25 15:33:47 +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
|
|
|
step = wp_pipewire_object_mixin_activate_get_next_step (object, transition,
|
|
|
|
|
step, missing);
|
2020-05-25 15:33:47 +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
|
|
|
/* extend the mixin's state machine; when the only remaining feature(s) to
|
|
|
|
|
enable are FEATURE_ENDPOINTS or FEATURE_LINKS, advance to STEP_CHILDREN */
|
|
|
|
|
if (step == WP_PIPEWIRE_OBJECT_MIXIN_STEP_CACHE_INFO &&
|
|
|
|
|
(missing & ~(WP_SESSION_FEATURE_ENDPOINTS | WP_SESSION_FEATURE_LINKS)) == 0)
|
|
|
|
|
return STEP_CHILDREN;
|
2020-05-25 15:33:47 +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
|
|
|
return step;
|
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) {
|
|
|
|
|
case WP_PIPEWIRE_OBJECT_MIXIN_STEP_CACHE_INFO:
|
|
|
|
|
wp_pipewire_object_mixin_cache_info (object, transition);
|
|
|
|
|
break;
|
|
|
|
|
case STEP_CHILDREN:
|
|
|
|
|
wp_session_enable_features_endpoints_links (WP_SESSION (object),
|
|
|
|
|
missing);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
WP_OBJECT_CLASS (wp_session_parent_class)->
|
|
|
|
|
activate_execute_step (object, transition, step, missing);
|
|
|
|
|
break;
|
|
|
|
|
}
|
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);
|
|
|
|
|
|
|
|
|
|
wp_pipewire_object_mixin_deactivate (object, features);
|
|
|
|
|
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
session_event_info (void *data, const struct pw_session_info *info)
|
|
|
|
|
{
|
2020-02-11 16:43:10 +02:00
|
|
|
WpSession *self = WP_SESSION (data);
|
|
|
|
|
WpSessionPrivate *priv = wp_session_get_instance_private (self);
|
2019-09-24 16:34:18 +03:00
|
|
|
|
2020-04-01 13:06:18 +03:00
|
|
|
priv->info = pw_session_info_update (priv->info, info);
|
|
|
|
|
|
|
|
|
|
if (info->change_mask & PW_SESSION_CHANGE_MASK_PROPS) {
|
|
|
|
|
g_clear_pointer (&priv->properties, wp_properties_unref);
|
|
|
|
|
priv->properties = wp_properties_new_wrap_dict (priv->info->props);
|
|
|
|
|
}
|
2020-01-30 17:41:25 +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_object_update_features (WP_OBJECT (self),
|
|
|
|
|
WP_PIPEWIRE_OBJECT_FEATURE_INFO, 0);
|
2020-05-25 15:33:47 +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_pipewire_object_mixin_handle_event_info (self, info,
|
|
|
|
|
PW_SESSION_CHANGE_MASK_PROPS, PW_SESSION_CHANGE_MASK_PARAMS);
|
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,
|
|
|
|
|
.info = session_event_info,
|
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
|
|
|
.param = wp_pipewire_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-02-11 16:43:10 +02:00
|
|
|
WpSession *self = WP_SESSION (proxy);
|
|
|
|
|
WpSessionPrivate *priv = wp_session_get_instance_private (self);
|
2020-04-01 13:06:18 +03:00
|
|
|
|
|
|
|
|
priv->iface = (struct pw_session *) pw_proxy;
|
|
|
|
|
pw_session_add_listener (priv->iface, &priv->listener, &session_events, self);
|
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
|
|
|
|
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_pointer (&priv->properties, wp_properties_unref);
|
|
|
|
|
g_clear_pointer (&priv->info, pw_session_info_free);
|
|
|
|
|
g_clear_object (&priv->endpoints_om);
|
|
|
|
|
g_clear_object (&priv->links_om);
|
|
|
|
|
wp_object_update_features (WP_OBJECT (self), 0,
|
|
|
|
|
WP_PIPEWIRE_OBJECT_FEATURE_INFO |
|
|
|
|
|
WP_SESSION_FEATURE_ENDPOINTS |
|
|
|
|
|
WP_SESSION_FEATURE_LINKS);
|
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
|
|
|
wp_pipewire_object_mixin_deactivate (WP_OBJECT (proxy),
|
|
|
|
|
WP_OBJECT_FEATURES_ALL);
|
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;
|
|
|
|
|
|
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
|
|
|
object_class->get_property = wp_pipewire_object_mixin_get_property;
|
|
|
|
|
|
|
|
|
|
wpobject_class->get_supported_features = wp_session_get_supported_features;
|
|
|
|
|
wpobject_class->activate_get_next_step = wp_session_activate_get_next_step;
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
|
|
wp_pipewire_object_mixin_class_override_properties (object_class);
|
2020-02-11 16:43:10 +02:00
|
|
|
|
2020-02-17 15:39:19 +02:00
|
|
|
/**
|
|
|
|
|
* WpSession::default-endpoint-changed:
|
|
|
|
|
* @self: the session
|
2020-05-25 18:51:23 +03:00
|
|
|
* @direction: the endpoint direction
|
2020-02-17 15:39:19 +02:00
|
|
|
* @id: the endpoint's bound id
|
|
|
|
|
*
|
2020-05-25 18:51:23 +03:00
|
|
|
* Emitted when the default endpoint of a specific direction changes.
|
2020-02-17 15:39:19 +02:00
|
|
|
* The passed @id is the bound id (wp_proxy_get_bound_id()) of the new
|
|
|
|
|
* default endpoint.
|
|
|
|
|
*/
|
2020-02-11 16:43:10 +02:00
|
|
|
signals[SIGNAL_DEFAULT_ENDPOINT_CHANGED] = g_signal_new (
|
|
|
|
|
"default-endpoint-changed", G_TYPE_FROM_CLASS (klass),
|
|
|
|
|
G_SIGNAL_RUN_LAST, 0, NULL, NULL, NULL, G_TYPE_NONE, 2,
|
2020-05-25 18:51:23 +03:00
|
|
|
WP_TYPE_DIRECTION, G_TYPE_UINT);
|
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
|
|
|
}
|
|
|
|
|
|
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 gconstpointer
|
|
|
|
|
wp_session_get_native_info (WpPipewireObject * obj)
|
2020-05-16 12:53:37 +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 *self = WP_SESSION (obj);
|
|
|
|
|
WpSessionPrivate *priv = wp_session_get_instance_private (self);
|
|
|
|
|
|
|
|
|
|
return priv->info;
|
|
|
|
|
}
|
2020-05-16 12:53:37 +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
|
|
|
static WpProperties *
|
|
|
|
|
wp_session_get_properties (WpPipewireObject * obj)
|
|
|
|
|
{
|
|
|
|
|
WpSession *self = WP_SESSION (obj);
|
2020-05-16 12:53:37 +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
|
|
|
|
|
|
|
|
return wp_properties_ref (priv->properties);
|
2020-05-16 12:53:37 +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
|
|
|
static GVariant *
|
|
|
|
|
wp_session_get_param_info (WpPipewireObject * obj)
|
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 *self = WP_SESSION (obj);
|
|
|
|
|
WpSessionPrivate *priv = wp_session_get_instance_private (self);
|
2020-05-25 18:51:23 +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
|
|
|
return wp_pipewire_object_mixin_param_info_to_gvariant (priv->info->params,
|
|
|
|
|
priv->info->n_params);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
wp_session_enum_params (WpPipewireObject * obj, const gchar * id,
|
|
|
|
|
WpSpaPod *filter, GCancellable * cancellable,
|
|
|
|
|
GAsyncReadyCallback callback, gpointer user_data)
|
|
|
|
|
{
|
|
|
|
|
wp_pipewire_object_mixin_enum_params (pw_session, obj, id, filter,
|
|
|
|
|
cancellable, callback, user_data);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
wp_session_set_param (WpPipewireObject * obj, const gchar * id,
|
|
|
|
|
WpSpaPod * param)
|
|
|
|
|
{
|
|
|
|
|
wp_pipewire_object_mixin_set_param (pw_session, obj, id, param);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
wp_session_pipewire_object_interface_init (
|
|
|
|
|
WpPipewireObjectInterface * iface)
|
|
|
|
|
{
|
|
|
|
|
iface->get_native_info = wp_session_get_native_info;
|
|
|
|
|
iface->get_properties = wp_session_get_properties;
|
|
|
|
|
iface->get_param_info = wp_session_get_param_info;
|
|
|
|
|
iface->enum_params = wp_session_enum_params;
|
|
|
|
|
iface->enum_params_finish = wp_pipewire_object_mixin_enum_params_finish;
|
|
|
|
|
iface->enum_cached_params = wp_pipewire_object_mixin_enum_cached_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
|
|
|
|
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 (self);
|
|
|
|
|
return wp_properties_get (priv->properties, "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);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2020-05-05 12:17:08 +03:00
|
|
|
* wp_session_iterate_endpoints:
|
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 *
|
|
|
|
|
wp_session_iterate_endpoints (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);
|
2020-05-05 12:17:08 +03:00
|
|
|
return wp_object_manager_iterate (priv->endpoints_om);
|
2020-04-01 13:38:39 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2020-05-05 12:17:08 +03:00
|
|
|
* wp_session_iterate_endpoints_filtered:
|
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 *
|
2020-05-05 12:17:08 +03:00
|
|
|
wp_session_iterate_endpoints_filtered (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_iterate_endpoints_filtered_full (self, interest);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* wp_session_iterate_endpoints_filtered_full: (rename-to wp_session_iterate_endpoints_filtered)
|
|
|
|
|
* @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 *
|
|
|
|
|
wp_session_iterate_endpoints_filtered_full (WpSession * self,
|
|
|
|
|
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);
|
2020-05-05 12:17:08 +03:00
|
|
|
return wp_object_manager_iterate_filtered_full (priv->endpoints_om, interest);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* 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);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2020-05-05 12:17:08 +03:00
|
|
|
* wp_session_iterate_links:
|
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 *
|
|
|
|
|
wp_session_iterate_links (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);
|
2020-05-05 12:17:08 +03:00
|
|
|
return wp_object_manager_iterate (priv->links_om);
|
2020-04-01 13:53:45 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2020-05-05 12:17:08 +03:00
|
|
|
* wp_session_iterate_links_filtered:
|
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 *
|
2020-05-05 12:17:08 +03:00
|
|
|
wp_session_iterate_links_filtered (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_iterate_links_filtered_full (self, interest);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* wp_session_iterate_links_filtered_full: (rename-to wp_session_iterate_links_filtered)
|
|
|
|
|
* @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 *
|
|
|
|
|
wp_session_iterate_links_filtered_full (WpSession * self,
|
|
|
|
|
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);
|
2020-05-05 12:17:08 +03:00
|
|
|
return wp_object_manager_iterate_filtered_full (priv->links_om, interest);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* 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;
|
|
|
|
|
struct spa_hook_list hooks;
|
2019-09-24 16:34:18 +03:00
|
|
|
struct pw_session_info info;
|
|
|
|
|
};
|
|
|
|
|
|
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-04-01 13:06:18 +03:00
|
|
|
G_DEFINE_TYPE (WpImplSession, wp_impl_session, WP_TYPE_SESSION)
|
2019-09-24 16:34:18 +03:00
|
|
|
|
2020-04-01 13:06:18 +03:00
|
|
|
#define pw_session_emit(hooks,method,version,...) \
|
|
|
|
|
spa_hook_list_call_simple(hooks, struct pw_session_events, \
|
|
|
|
|
method, version, ##__VA_ARGS__)
|
2019-09-24 16:34:18 +03:00
|
|
|
|
2020-04-01 13:06:18 +03:00
|
|
|
#define pw_session_emit_info(hooks,...) pw_session_emit(hooks, info, 0, ##__VA_ARGS__)
|
|
|
|
|
#define pw_session_emit_param(hooks,...) pw_session_emit(hooks, param, 0, ##__VA_ARGS__)
|
2019-09-24 16:34:18 +03:00
|
|
|
|
2020-04-01 13:06:18 +03:00
|
|
|
static int
|
|
|
|
|
impl_add_listener(void *object,
|
|
|
|
|
struct spa_hook *listener,
|
|
|
|
|
const struct pw_session_events *events,
|
|
|
|
|
void *data)
|
2019-09-24 16:34:18 +03:00
|
|
|
{
|
2020-04-01 13:06:18 +03:00
|
|
|
WpImplSession *self = WP_IMPL_SESSION (object);
|
|
|
|
|
struct spa_hook_list save;
|
2019-09-24 16:34:18 +03:00
|
|
|
|
2020-04-01 13:06:18 +03:00
|
|
|
spa_hook_list_isolate (&self->hooks, &save, listener, events, data);
|
2019-09-24 16:34:18 +03:00
|
|
|
|
2020-04-01 13:06:18 +03:00
|
|
|
self->info.change_mask = PW_SESSION_CHANGE_MASK_ALL;
|
|
|
|
|
pw_session_emit_info (&self->hooks, &self->info);
|
|
|
|
|
self->info.change_mask = 0;
|
|
|
|
|
|
|
|
|
|
spa_hook_list_join (&self->hooks, &save);
|
|
|
|
|
return 0;
|
2019-09-24 16:34:18 +03:00
|
|
|
}
|
|
|
|
|
|
2020-04-01 13:06:18 +03:00
|
|
|
static int
|
|
|
|
|
impl_enum_params (void *object, int seq,
|
|
|
|
|
uint32_t id, uint32_t start, uint32_t num,
|
|
|
|
|
const struct spa_pod *filter)
|
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
|
|
|
return -ENOENT;
|
2020-04-01 13:06:18 +03:00
|
|
|
}
|
2019-09-24 16:34:18 +03:00
|
|
|
|
2020-04-01 13:06:18 +03:00
|
|
|
static int
|
|
|
|
|
impl_subscribe_params (void *object, uint32_t *ids, uint32_t n_ids)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
2019-09-24 16:34:18 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int
|
2020-04-01 13:06:18 +03:00
|
|
|
impl_set_param (void *object, uint32_t id, uint32_t flags,
|
|
|
|
|
const struct spa_pod *param)
|
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
|
|
|
return -ENOENT;
|
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,
|
|
|
|
|
.add_listener = impl_add_listener,
|
|
|
|
|
.subscribe_params = impl_subscribe_params,
|
|
|
|
|
.enum_params = impl_enum_params,
|
|
|
|
|
.set_param = 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)
|
|
|
|
|
{
|
|
|
|
|
/* reuse the parent's private to optimize memory usage and to be able
|
|
|
|
|
to re-use some of the parent's methods without reimplementing them */
|
2020-04-16 15:18:53 -04:00
|
|
|
WpSessionPrivate *priv = wp_session_get_instance_private (WP_SESSION (self));
|
2020-04-01 13:06:18 +03:00
|
|
|
|
|
|
|
|
self->iface = SPA_INTERFACE_INIT (
|
|
|
|
|
PW_TYPE_INTERFACE_Session,
|
|
|
|
|
PW_VERSION_SESSION,
|
|
|
|
|
&impl_session, self);
|
|
|
|
|
spa_hook_list_init (&self->hooks);
|
|
|
|
|
|
|
|
|
|
priv->iface = (struct pw_session *) &self->iface;
|
|
|
|
|
|
|
|
|
|
/* prepare INFO */
|
|
|
|
|
priv->properties = wp_properties_new_empty ();
|
|
|
|
|
self->info.version = PW_VERSION_SESSION_INFO;
|
|
|
|
|
self->info.props =
|
|
|
|
|
(struct spa_dict *) wp_properties_peek_dict (priv->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-04-01 13:06:18 +03:00
|
|
|
priv->info = &self->info;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
wp_impl_session_finalize (GObject * object)
|
|
|
|
|
{
|
|
|
|
|
WpSessionPrivate *priv = wp_session_get_instance_private (WP_SESSION (object));
|
|
|
|
|
|
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_pointer (&priv->properties, wp_properties_unref);
|
2020-04-01 13:06:18 +03:00
|
|
|
|
|
|
|
|
G_OBJECT_CLASS (wp_impl_session_parent_class)->finalize (object);
|
|
|
|
|
}
|
|
|
|
|
|
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-04-01 13:06:18 +03:00
|
|
|
WpSessionPrivate *priv = wp_session_get_instance_private (WP_SESSION (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) {
|
|
|
|
|
case WP_PIPEWIRE_OBJECT_MIXIN_STEP_BIND: {
|
|
|
|
|
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-04-01 13:06:18 +03:00
|
|
|
wp_properties_set (priv->properties, PW_KEY_OBJECT_ID, NULL);
|
|
|
|
|
wp_properties_set (priv->properties, PW_KEY_CLIENT_ID, NULL);
|
|
|
|
|
wp_properties_set (priv->properties, PW_KEY_FACTORY_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_proxy_set_pw_proxy (WP_PROXY (self), pw_core_export (pw_core,
|
2020-04-01 13:06:18 +03:00
|
|
|
PW_TYPE_INTERFACE_Session,
|
|
|
|
|
wp_properties_peek_dict (priv->properties),
|
|
|
|
|
priv->iface, 0));
|
2020-04-01 13:38:39 +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_object_update_features (WP_OBJECT (self),
|
|
|
|
|
WP_PIPEWIRE_OBJECT_FEATURE_INFO, 0);
|
|
|
|
|
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_PIPEWIRE_OBJECT_FEATURE_INFO |
|
|
|
|
|
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-02-11 16:43:10 +02:00
|
|
|
object_class->finalize = wp_impl_session_finalize;
|
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-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-04-01 13:06:18 +03:00
|
|
|
WpSessionPrivate *priv;
|
2019-09-24 16:34:18 +03:00
|
|
|
|
2020-02-11 16:43:10 +02:00
|
|
|
g_return_if_fail (WP_IS_IMPL_SESSION (self));
|
2020-04-01 13:06:18 +03:00
|
|
|
priv = wp_session_get_instance_private (WP_SESSION (self));
|
2019-09-24 16:34:18 +03:00
|
|
|
|
2020-04-01 13:06:18 +03:00
|
|
|
wp_properties_set (priv->properties, key, value);
|
2019-09-24 16:34:18 +03:00
|
|
|
|
|
|
|
|
g_object_notify (G_OBJECT (self), "properties");
|
|
|
|
|
|
|
|
|
|
/* update only after the session has been exported */
|
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 (wp_object_get_active_features (WP_OBJECT (self)) & WP_PROXY_FEATURE_BOUND) {
|
2020-04-01 13:06:18 +03:00
|
|
|
self->info.change_mask = PW_SESSION_CHANGE_MASK_PROPS;
|
|
|
|
|
pw_session_emit_info (&self->hooks, &self->info);
|
|
|
|
|
self->info.change_mask = 0;
|
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-04-01 13:06:18 +03:00
|
|
|
WpSessionPrivate *priv;
|
2019-09-24 16:34:18 +03:00
|
|
|
|
2020-02-11 16:43:10 +02:00
|
|
|
g_return_if_fail (WP_IS_IMPL_SESSION (self));
|
2020-04-01 13:06:18 +03:00
|
|
|
priv = wp_session_get_instance_private (WP_SESSION (self));
|
2019-09-24 16:34:18 +03:00
|
|
|
|
2020-04-01 13:06:18 +03:00
|
|
|
wp_properties_update (priv->properties, updates);
|
2019-09-24 16:34:18 +03:00
|
|
|
|
|
|
|
|
g_object_notify (G_OBJECT (self), "properties");
|
|
|
|
|
|
|
|
|
|
/* update only after the session has been exported */
|
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 (wp_object_get_active_features (WP_OBJECT (self)) & WP_PROXY_FEATURE_BOUND) {
|
2020-04-01 13:06:18 +03:00
|
|
|
self->info.change_mask = PW_SESSION_CHANGE_MASK_PROPS;
|
|
|
|
|
pw_session_emit_info (&self->hooks, &self->info);
|
|
|
|
|
self->info.change_mask = 0;
|
2019-09-24 16:34:18 +03:00
|
|
|
}
|
|
|
|
|
}
|