2020-01-08 09:25:24 -05:00
|
|
|
/* WirePlumber
|
|
|
|
|
*
|
2020-01-30 17:41:25 +02:00
|
|
|
* Copyright © 2019-2020 Collabora Ltd.
|
2020-01-08 09:25:24 -05:00
|
|
|
* @author Julian Bouzas <julian.bouzas@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: device
|
|
|
|
|
* @title: PipeWire Device
|
2020-02-17 15:39:19 +02:00
|
|
|
*/
|
|
|
|
|
|
2020-04-14 18:31:17 +03:00
|
|
|
#define G_LOG_DOMAIN "wp-device"
|
|
|
|
|
|
2020-01-22 18:54:45 +02:00
|
|
|
#include "device.h"
|
2020-01-30 17:41:25 +02:00
|
|
|
#include "node.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 "core.h"
|
2020-11-25 14:02:33 +02:00
|
|
|
#include "debug.h"
|
2021-01-18 17:13:15 +02:00
|
|
|
#include "error.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"
|
2020-01-08 09:25:24 -05:00
|
|
|
|
2020-01-30 17:41:25 +02:00
|
|
|
#include <pipewire/impl.h>
|
2021-01-18 17:13:15 +02:00
|
|
|
#include <spa/debug/types.h>
|
2020-01-30 17:41:25 +02:00
|
|
|
#include <spa/monitor/device.h>
|
2020-11-25 14:02:33 +02:00
|
|
|
#include <spa/utils/result.h>
|
2020-01-08 09:25:24 -05:00
|
|
|
|
2020-01-22 18:54:45 +02:00
|
|
|
struct _WpDevice
|
2020-01-08 09:25:24 -05: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
|
|
|
WpGlobalProxy parent;
|
2020-01-08 09:25:24 -05:00
|
|
|
};
|
|
|
|
|
|
2020-11-25 14:02:33 +02:00
|
|
|
static void wp_device_pw_object_mixin_priv_interface_init (
|
|
|
|
|
WpPwObjectMixinPrivInterface * iface);
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* WpDevice:
|
|
|
|
|
*
|
|
|
|
|
* The #WpDevice class allows accessing the properties and methods of a
|
|
|
|
|
* PipeWire device object (`struct pw_device`).
|
|
|
|
|
*
|
|
|
|
|
* A #WpDevice is constructed internally when a new device appears on the
|
|
|
|
|
* PipeWire registry and it is made available through the #WpObjectManager API.
|
|
|
|
|
* Alternatively, a #WpDevice can also be constructed using
|
|
|
|
|
* wp_device_new_from_factory(), which creates a new device object
|
|
|
|
|
* on the remote PipeWire server by calling into a factory.
|
|
|
|
|
*/
|
|
|
|
|
G_DEFINE_TYPE_WITH_CODE (WpDevice, wp_device, WP_TYPE_GLOBAL_PROXY,
|
2020-11-25 14:02:33 +02:00
|
|
|
G_IMPLEMENT_INTERFACE (WP_TYPE_PIPEWIRE_OBJECT,
|
|
|
|
|
wp_pw_object_mixin_object_interface_init)
|
|
|
|
|
G_IMPLEMENT_INTERFACE (WP_TYPE_PW_OBJECT_MIXIN_PRIV,
|
|
|
|
|
wp_device_pw_object_mixin_priv_interface_init));
|
2020-01-08 09:25:24 -05:00
|
|
|
|
|
|
|
|
static void
|
2020-01-22 18:54:45 +02:00
|
|
|
wp_device_init (WpDevice * self)
|
2020-01-08 09:25:24 -05: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_device_activate_execute_step (WpObject * object,
|
|
|
|
|
WpFeatureActivationTransition * transition, guint step,
|
|
|
|
|
WpObjectFeatures missing)
|
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
|
|
|
switch (step) {
|
2020-11-25 14:02:33 +02:00
|
|
|
case WP_PW_OBJECT_MIXIN_STEP_BIND:
|
|
|
|
|
case WP_TRANSITION_STEP_ERROR:
|
|
|
|
|
/* base class can handle BIND and ERROR */
|
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_CLASS (wp_device_parent_class)->
|
|
|
|
|
activate_execute_step (object, transition, step, missing);
|
|
|
|
|
break;
|
2020-11-25 14:02:33 +02:00
|
|
|
case WP_PW_OBJECT_MIXIN_STEP_WAIT_INFO:
|
|
|
|
|
/* just wait, info will be emitted anyway after binding */
|
|
|
|
|
break;
|
|
|
|
|
case WP_PW_OBJECT_MIXIN_STEP_CACHE_PARAMS:
|
|
|
|
|
wp_pw_object_mixin_cache_params (object, missing);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
g_assert_not_reached ();
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
}
|
2020-05-25 15:33:47 +03:00
|
|
|
}
|
2020-01-08 09:25:24 -05: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_device_deactivate (WpObject * object, WpObjectFeatures features)
|
2020-05-25 15:33:47 +03:00
|
|
|
{
|
2020-11-25 14:02:33 +02:00
|
|
|
wp_pw_object_mixin_deactivate (object, features);
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
WP_OBJECT_CLASS (wp_device_parent_class)->deactivate (object, features);
|
2020-01-08 09:25:24 -05:00
|
|
|
}
|
|
|
|
|
|
2020-01-09 12:39:45 -05:00
|
|
|
static const struct pw_device_events device_events = {
|
|
|
|
|
PW_VERSION_DEVICE_EVENTS,
|
2020-11-25 14:02:33 +02:00
|
|
|
.info = (HandleEventInfoFunc(device)) wp_pw_object_mixin_handle_event_info,
|
|
|
|
|
.param = wp_pw_object_mixin_handle_event_param,
|
2020-01-08 09:25:24 -05:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static void
|
2020-01-22 18:54:45 +02:00
|
|
|
wp_device_pw_proxy_created (WpProxy * proxy, struct pw_proxy * pw_proxy)
|
2020-01-08 09:25:24 -05:00
|
|
|
{
|
2020-11-25 14:02:33 +02:00
|
|
|
wp_pw_object_mixin_handle_pw_proxy_created (proxy, pw_proxy,
|
|
|
|
|
device, &device_events);
|
2020-01-08 09:25:24 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2020-01-22 18:54:45 +02:00
|
|
|
wp_device_class_init (WpDeviceClass * klass)
|
2020-01-08 09:25:24 -05: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-01-08 09:25:24 -05:00
|
|
|
WpProxyClass *proxy_class = (WpProxyClass *) klass;
|
|
|
|
|
|
2020-11-25 14:02:33 +02:00
|
|
|
object_class->get_property = wp_pw_object_mixin_get_property;
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
|
2020-11-25 14:02:33 +02:00
|
|
|
wpobject_class->get_supported_features =
|
|
|
|
|
wp_pw_object_mixin_get_supported_features;
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
wpobject_class->activate_get_next_step =
|
2020-11-25 14:02:33 +02:00
|
|
|
wp_pw_object_mixin_activate_get_next_step;
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
wpobject_class->activate_execute_step = wp_device_activate_execute_step;
|
|
|
|
|
wpobject_class->deactivate = wp_device_deactivate;
|
2020-01-08 09:25:24 -05:00
|
|
|
|
2020-01-30 17:41:25 +02:00
|
|
|
proxy_class->pw_iface_type = PW_TYPE_INTERFACE_Device;
|
|
|
|
|
proxy_class->pw_iface_version = PW_VERSION_DEVICE;
|
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_created = wp_device_pw_proxy_created;
|
2020-11-25 14:02:33 +02:00
|
|
|
proxy_class->pw_proxy_destroyed =
|
|
|
|
|
wp_pw_object_mixin_handle_pw_proxy_destroyed;
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
|
2020-11-25 14:02:33 +02:00
|
|
|
wp_pw_object_mixin_class_override_properties (object_class);
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
}
|
|
|
|
|
|
2020-11-25 14:02:33 +02:00
|
|
|
static gint
|
|
|
|
|
wp_device_enum_params (gpointer instance, guint32 id,
|
|
|
|
|
guint32 start, guint32 num, WpSpaPod *filter)
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
{
|
2020-11-25 14:02:33 +02:00
|
|
|
WpPwObjectMixinData *d = wp_pw_object_mixin_get_data (instance);
|
|
|
|
|
return pw_device_enum_params (d->iface, 0, id, start, num,
|
|
|
|
|
filter ? wp_spa_pod_get_spa_pod (filter) : 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
|
|
|
}
|
|
|
|
|
|
2020-11-25 14:02:33 +02:00
|
|
|
static gint
|
|
|
|
|
wp_device_set_param (gpointer instance, guint32 id, guint32 flags,
|
|
|
|
|
WpSpaPod * param)
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
{
|
2020-11-25 14:02:33 +02:00
|
|
|
WpPwObjectMixinData *d = wp_pw_object_mixin_get_data (instance);
|
|
|
|
|
return pw_device_set_param (d->iface, id, flags,
|
|
|
|
|
wp_spa_pod_get_spa_pod (param));
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2020-11-25 14:02:33 +02:00
|
|
|
wp_device_pw_object_mixin_priv_interface_init (
|
|
|
|
|
WpPwObjectMixinPrivInterface * iface)
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
{
|
2020-11-25 14:02:33 +02:00
|
|
|
wp_pw_object_mixin_priv_interface_info_init (iface, device, DEVICE);
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
iface->enum_params = wp_device_enum_params;
|
|
|
|
|
iface->set_param = wp_device_set_param;
|
2020-01-08 09:25:24 -05:00
|
|
|
}
|
2020-01-30 17:41:25 +02:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* wp_device_new_from_factory:
|
|
|
|
|
* @core: the wireplumber core
|
|
|
|
|
* @factory_name: the pipewire factory name to construct the device
|
|
|
|
|
* @properties: (nullable) (transfer full): the properties to pass to the factory
|
|
|
|
|
*
|
|
|
|
|
* Constructs a device on the PipeWire server by asking the remote factory
|
|
|
|
|
* @factory_name to create it.
|
|
|
|
|
*
|
|
|
|
|
* Because of the nature of the PipeWire protocol, this operation completes
|
|
|
|
|
* asynchronously at some point in the future. In order to find out when
|
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
|
|
|
* this is done, you should call wp_object_activate(), requesting at least
|
2020-01-30 17:41:25 +02:00
|
|
|
* %WP_PROXY_FEATURE_BOUND. When this feature is ready, the device is ready for
|
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
|
|
|
* use on the server. If the device cannot be created, this activation operation
|
2020-01-30 17:41:25 +02:00
|
|
|
* will fail.
|
|
|
|
|
*
|
|
|
|
|
* Returns: (nullable) (transfer full): the new device or %NULL if the core
|
|
|
|
|
* is not connected and therefore the device cannot be created
|
|
|
|
|
*/
|
|
|
|
|
WpDevice *
|
|
|
|
|
wp_device_new_from_factory (WpCore * core,
|
|
|
|
|
const gchar * factory_name, WpProperties * properties)
|
|
|
|
|
{
|
|
|
|
|
g_autoptr (WpProperties) props = properties;
|
|
|
|
|
WpDevice *self = NULL;
|
|
|
|
|
struct pw_core *pw_core = wp_core_get_pw_core (core);
|
|
|
|
|
|
2020-04-14 18:31:17 +03:00
|
|
|
if (G_UNLIKELY (!pw_core)) {
|
|
|
|
|
g_critical ("The WirePlumber core is not connected; "
|
|
|
|
|
"device cannot be created");
|
2020-01-30 17:41:25 +02:00
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self = g_object_new (WP_TYPE_DEVICE, "core", core, NULL);
|
|
|
|
|
wp_proxy_set_pw_proxy (WP_PROXY (self), pw_core_create_object (pw_core,
|
|
|
|
|
factory_name, PW_TYPE_INTERFACE_Device, PW_VERSION_DEVICE,
|
|
|
|
|
props ? wp_properties_peek_dict (props) : NULL, 0));
|
|
|
|
|
return self;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2020-06-10 15:34:34 -04:00
|
|
|
enum {
|
|
|
|
|
PROP_0,
|
|
|
|
|
PROP_SPA_DEVICE_HANDLE,
|
2020-06-15 11:10:39 +03:00
|
|
|
PROP_PROPERTIES,
|
2020-06-10 15:34:34 -04:00
|
|
|
};
|
|
|
|
|
|
2020-01-30 17:41:25 +02:00
|
|
|
struct _WpSpaDevice
|
|
|
|
|
{
|
2021-01-18 17:13:15 +02:00
|
|
|
WpProxy parent;
|
2020-01-30 17:41:25 +02:00
|
|
|
struct spa_handle *handle;
|
2020-06-10 15:34:34 -04:00
|
|
|
struct spa_device *device;
|
2020-01-30 17:41:25 +02:00
|
|
|
struct spa_hook listener;
|
|
|
|
|
WpProperties *properties;
|
2021-01-18 17:13:15 +02:00
|
|
|
GPtrArray *managed_objs;
|
2020-01-30 17:41:25 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum
|
|
|
|
|
{
|
2021-01-18 17:13:15 +02:00
|
|
|
SIGNAL_CREATE_OBJECT,
|
2021-01-26 16:42:29 +02:00
|
|
|
SIGNAL_OBJECT_REMOVED,
|
2020-01-30 17:41:25 +02:00
|
|
|
SPA_DEVICE_LAST_SIGNAL,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static guint spa_device_signals[SPA_DEVICE_LAST_SIGNAL] = { 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
|
|
|
/**
|
|
|
|
|
* WpSpaDevice:
|
|
|
|
|
*
|
|
|
|
|
* A #WpSpaDevice allows running a `spa_device` object locally,
|
|
|
|
|
* loading the implementation from a SPA factory. This is useful to run device
|
|
|
|
|
* monitors inside the session manager and have control over creating the
|
|
|
|
|
* actual nodes that the `spa_device` requests to create.
|
2021-01-18 17:13:15 +02:00
|
|
|
*
|
|
|
|
|
* To enable the spa device, call wp_object_activate() requesting
|
|
|
|
|
* %WP_SPA_DEVICE_FEATURE_ENABLED.
|
|
|
|
|
*
|
|
|
|
|
* For actual devices (not device monitors) it also possible and desirable
|
|
|
|
|
* to export the device to PipeWire, which can be done by requesting
|
|
|
|
|
* %WP_PROXY_FEATURE_BOUND from wp_object_activate(). When exporting, the
|
|
|
|
|
* export should be done before enabling the device, by requesting both
|
|
|
|
|
* features at the same time.
|
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
|
|
|
*/
|
2021-01-18 17:13:15 +02:00
|
|
|
G_DEFINE_TYPE (WpSpaDevice, wp_spa_device, WP_TYPE_PROXY)
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
object_unref_safe (gpointer object)
|
|
|
|
|
{
|
|
|
|
|
if (object)
|
|
|
|
|
g_object_unref (object);
|
|
|
|
|
}
|
2020-01-30 17:41:25 +02:00
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
wp_spa_device_init (WpSpaDevice * self)
|
|
|
|
|
{
|
2020-06-10 15:34:34 -04:00
|
|
|
self->properties = wp_properties_new_empty ();
|
2021-01-18 17:13:15 +02:00
|
|
|
self->managed_objs = g_ptr_array_new_with_free_func (object_unref_safe);
|
2020-06-10 15:34:34 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
wp_spa_device_constructed (GObject *object)
|
|
|
|
|
{
|
|
|
|
|
WpSpaDevice *self = WP_SPA_DEVICE (object);
|
|
|
|
|
gint res;
|
|
|
|
|
|
|
|
|
|
g_return_if_fail (self->handle);
|
|
|
|
|
|
|
|
|
|
/* Get the handle interface */
|
|
|
|
|
res = spa_handle_get_interface (self->handle, SPA_TYPE_INTERFACE_Device,
|
|
|
|
|
(gpointer *) &self->device);
|
|
|
|
|
if (res < 0) {
|
|
|
|
|
wp_warning_object (self,
|
|
|
|
|
"Could not get device interface from SPA handle: %s",
|
|
|
|
|
spa_strerror (res));
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
G_OBJECT_CLASS (wp_spa_device_parent_class)->constructed (object);
|
2020-01-30 17:41:25 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
wp_spa_device_finalize (GObject * object)
|
|
|
|
|
{
|
|
|
|
|
WpSpaDevice *self = WP_SPA_DEVICE (object);
|
|
|
|
|
|
2020-06-10 15:34:34 -04:00
|
|
|
self->device = NULL;
|
2020-01-30 17:41:25 +02:00
|
|
|
g_clear_pointer (&self->handle, pw_unload_spa_handle);
|
|
|
|
|
g_clear_pointer (&self->properties, wp_properties_unref);
|
2021-01-18 17:13:15 +02:00
|
|
|
g_clear_pointer (&self->managed_objs, g_ptr_array_unref);
|
2020-01-30 17:41:25 +02:00
|
|
|
|
|
|
|
|
G_OBJECT_CLASS (wp_spa_device_parent_class)->finalize (object);
|
|
|
|
|
}
|
|
|
|
|
|
2020-06-10 15:34:34 -04:00
|
|
|
static void
|
|
|
|
|
wp_spa_device_set_property (GObject * object, guint property_id,
|
|
|
|
|
const GValue * value, GParamSpec * pspec)
|
|
|
|
|
{
|
|
|
|
|
WpSpaDevice *self = WP_SPA_DEVICE (object);
|
|
|
|
|
|
|
|
|
|
switch (property_id) {
|
|
|
|
|
case PROP_SPA_DEVICE_HANDLE:
|
|
|
|
|
self->handle = g_value_get_pointer (value);
|
|
|
|
|
break;
|
2020-06-15 11:10:39 +03:00
|
|
|
case PROP_PROPERTIES: {
|
|
|
|
|
WpProperties *p = g_value_get_boxed (value);
|
|
|
|
|
if (p)
|
|
|
|
|
wp_properties_update (self->properties, p);
|
|
|
|
|
break;
|
|
|
|
|
}
|
2020-06-10 15:34:34 -04:00
|
|
|
default:
|
|
|
|
|
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, property_id, pspec);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
wp_spa_device_get_property (GObject * object, guint property_id, GValue * value,
|
|
|
|
|
GParamSpec * pspec)
|
|
|
|
|
{
|
|
|
|
|
WpSpaDevice *self = WP_SPA_DEVICE (object);
|
|
|
|
|
|
|
|
|
|
switch (property_id) {
|
|
|
|
|
case PROP_SPA_DEVICE_HANDLE:
|
|
|
|
|
g_value_set_pointer (value, self->handle);
|
|
|
|
|
break;
|
2020-06-15 11:10:39 +03:00
|
|
|
case PROP_PROPERTIES:
|
|
|
|
|
g_value_take_boxed (value, wp_properties_ref (self->properties));
|
|
|
|
|
break;
|
2020-06-10 15:34:34 -04:00
|
|
|
default:
|
|
|
|
|
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, property_id, pspec);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-30 17:41:25 +02:00
|
|
|
static void
|
|
|
|
|
spa_device_event_info (void *data, const struct spa_device_info *info)
|
|
|
|
|
{
|
|
|
|
|
WpSpaDevice *self = WP_SPA_DEVICE (data);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* This is emited syncrhonously at the time we add the listener and
|
|
|
|
|
* before object_info is emited. It gives us additional properties
|
|
|
|
|
* about the device, like the "api.alsa.card.*" ones that are not
|
|
|
|
|
* set by the monitor
|
|
|
|
|
*/
|
|
|
|
|
if (info->change_mask & SPA_DEVICE_CHANGE_MASK_PROPS)
|
|
|
|
|
wp_properties_update_from_dict (self->properties, info->props);
|
|
|
|
|
}
|
|
|
|
|
|
2021-01-20 16:46:55 +02:00
|
|
|
static void
|
|
|
|
|
spa_device_event_event (void *data, const struct spa_event *event)
|
|
|
|
|
{
|
|
|
|
|
WpSpaDevice *self = WP_SPA_DEVICE (data);
|
|
|
|
|
g_autoptr (WpSpaPod) pod =
|
|
|
|
|
wp_spa_pod_new_wrap_const ((const struct spa_pod *) event);
|
2021-04-16 20:01:56 +03:00
|
|
|
guint32 id = -1;
|
|
|
|
|
const gchar *type = NULL;
|
2021-01-20 16:46:55 +02:00
|
|
|
g_autoptr (WpSpaPod) props = NULL;
|
|
|
|
|
g_autoptr (GObject) child = NULL;
|
|
|
|
|
|
2021-04-16 20:01:56 +03:00
|
|
|
wp_trace_boxed (WP_TYPE_SPA_POD, pod, "device event");
|
2021-01-20 16:46:55 +02:00
|
|
|
|
2021-04-16 20:01:56 +03:00
|
|
|
if (wp_spa_pod_get_object (pod, &type,
|
|
|
|
|
"Object", "i", &id,
|
|
|
|
|
"Props", "?P", &props,
|
|
|
|
|
NULL))
|
|
|
|
|
child = wp_spa_device_get_managed_object (self, id);
|
2021-01-20 16:46:55 +02:00
|
|
|
|
|
|
|
|
if (child && !g_strcmp0 (type, "ObjectConfig") &&
|
|
|
|
|
WP_IS_PIPEWIRE_OBJECT (child) && props) {
|
|
|
|
|
wp_pipewire_object_set_param (WP_PIPEWIRE_OBJECT (child), "Props", 0, props);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-30 17:41:25 +02:00
|
|
|
static void
|
|
|
|
|
spa_device_event_object_info (void *data, uint32_t id,
|
|
|
|
|
const struct spa_device_object_info *info)
|
|
|
|
|
{
|
|
|
|
|
WpSpaDevice *self = WP_SPA_DEVICE (data);
|
|
|
|
|
|
|
|
|
|
if (info) {
|
2021-01-18 17:13:15 +02:00
|
|
|
const gchar *type;
|
|
|
|
|
g_autoptr (WpProperties) props = NULL;
|
2020-01-30 17:41:25 +02:00
|
|
|
|
2021-01-18 17:13:15 +02:00
|
|
|
type = spa_debug_type_short_name (info->type);
|
2020-01-30 17:41:25 +02:00
|
|
|
props = wp_properties_new_wrap_dict (info->props);
|
|
|
|
|
|
2021-01-18 17:13:15 +02:00
|
|
|
g_signal_emit (self, spa_device_signals[SIGNAL_CREATE_OBJECT], 0,
|
|
|
|
|
id, type, info->factory_name, props);
|
|
|
|
|
}
|
|
|
|
|
else {
|
2021-01-26 16:42:29 +02:00
|
|
|
g_signal_emit (self, spa_device_signals[SIGNAL_OBJECT_REMOVED], 0, id);
|
2021-01-18 17:13:15 +02:00
|
|
|
wp_spa_device_store_managed_object (self, id, NULL);
|
|
|
|
|
}
|
2020-01-30 17:41:25 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const struct spa_device_events spa_device_events = {
|
|
|
|
|
SPA_VERSION_DEVICE_EVENTS,
|
|
|
|
|
.info = spa_device_event_info,
|
2021-01-20 16:46:55 +02:00
|
|
|
.event = spa_device_event_event,
|
|
|
|
|
.object_info = spa_device_event_object_info,
|
2020-01-30 17:41:25 +02:00
|
|
|
};
|
|
|
|
|
|
2021-01-18 17:13:15 +02:00
|
|
|
static WpObjectFeatures
|
|
|
|
|
wp_spa_device_get_supported_features (WpObject * object)
|
|
|
|
|
{
|
|
|
|
|
return WP_PROXY_FEATURE_BOUND | WP_SPA_DEVICE_FEATURE_ENABLED;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
enum {
|
|
|
|
|
STEP_EXPORT = WP_TRANSITION_STEP_CUSTOM_START,
|
|
|
|
|
STEP_ADD_DEVICE_LISTENER,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static guint
|
|
|
|
|
wp_spa_device_activate_get_next_step (WpObject * object,
|
|
|
|
|
WpFeatureActivationTransition * transition, guint step,
|
|
|
|
|
WpObjectFeatures missing)
|
|
|
|
|
{
|
|
|
|
|
if (missing & WP_PROXY_FEATURE_BOUND)
|
|
|
|
|
return STEP_EXPORT;
|
|
|
|
|
else if (missing & WP_SPA_DEVICE_FEATURE_ENABLED)
|
|
|
|
|
return STEP_ADD_DEVICE_LISTENER;
|
|
|
|
|
else
|
|
|
|
|
return WP_TRANSITION_STEP_NONE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
wp_spa_device_activate_execute_step (WpObject * object,
|
|
|
|
|
WpFeatureActivationTransition * transition, guint step,
|
|
|
|
|
WpObjectFeatures missing)
|
|
|
|
|
{
|
|
|
|
|
WpSpaDevice *self = WP_SPA_DEVICE (object);
|
|
|
|
|
|
|
|
|
|
switch (step) {
|
|
|
|
|
case STEP_EXPORT: {
|
|
|
|
|
g_autoptr (WpCore) core = wp_object_get_core (object);
|
|
|
|
|
struct pw_core *pw_core = wp_core_get_pw_core (core);
|
|
|
|
|
g_return_if_fail (pw_core);
|
|
|
|
|
|
|
|
|
|
wp_proxy_set_pw_proxy (WP_PROXY (self),
|
|
|
|
|
pw_core_export (pw_core, SPA_TYPE_INTERFACE_Device,
|
|
|
|
|
wp_properties_peek_dict (self->properties),
|
|
|
|
|
self->device, 0));
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case STEP_ADD_DEVICE_LISTENER: {
|
|
|
|
|
gint res = spa_device_add_listener (self->device, &self->listener,
|
|
|
|
|
&spa_device_events, self);
|
|
|
|
|
if (res < 0)
|
|
|
|
|
wp_transition_return_error (WP_TRANSITION (transition),
|
|
|
|
|
g_error_new (WP_DOMAIN_LIBRARY, WP_LIBRARY_ERROR_OPERATION_FAILED,
|
|
|
|
|
"failed to activate device: %s", spa_strerror (res)));
|
|
|
|
|
else
|
|
|
|
|
wp_object_update_features (object, WP_SPA_DEVICE_FEATURE_ENABLED, 0);
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-03-16 16:15:32 +02:00
|
|
|
case WP_TRANSITION_STEP_ERROR:
|
|
|
|
|
break;
|
2021-01-18 17:13:15 +02:00
|
|
|
default:
|
|
|
|
|
g_assert_not_reached ();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
wp_spa_device_deactivate (WpObject * object, WpObjectFeatures features)
|
|
|
|
|
{
|
|
|
|
|
WP_OBJECT_CLASS (wp_spa_device_parent_class)->deactivate (object, features);
|
|
|
|
|
|
|
|
|
|
if (features & WP_SPA_DEVICE_FEATURE_ENABLED) {
|
|
|
|
|
WpSpaDevice *self = WP_SPA_DEVICE (object);
|
|
|
|
|
spa_hook_remove (&self->listener);
|
|
|
|
|
g_ptr_array_set_size (self->managed_objs, 0);
|
|
|
|
|
wp_object_update_features (object, 0, WP_SPA_DEVICE_FEATURE_ENABLED);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-30 17:41:25 +02:00
|
|
|
static void
|
|
|
|
|
wp_spa_device_class_init (WpSpaDeviceClass * klass)
|
|
|
|
|
{
|
|
|
|
|
GObjectClass *object_class = (GObjectClass *) klass;
|
2021-01-18 17:13:15 +02:00
|
|
|
WpObjectClass *wpobject_class = (WpObjectClass *) klass;
|
2020-01-30 17:41:25 +02:00
|
|
|
|
2020-06-10 15:34:34 -04:00
|
|
|
object_class->constructed = wp_spa_device_constructed;
|
2020-01-30 17:41:25 +02:00
|
|
|
object_class->finalize = wp_spa_device_finalize;
|
2020-06-10 15:34:34 -04:00
|
|
|
object_class->set_property = wp_spa_device_set_property;
|
|
|
|
|
object_class->get_property = wp_spa_device_get_property;
|
2020-01-30 17:41:25 +02:00
|
|
|
|
2021-01-18 17:13:15 +02:00
|
|
|
wpobject_class->get_supported_features = wp_spa_device_get_supported_features;
|
|
|
|
|
wpobject_class->activate_get_next_step = wp_spa_device_activate_get_next_step;
|
|
|
|
|
wpobject_class->activate_execute_step = wp_spa_device_activate_execute_step;
|
|
|
|
|
wpobject_class->deactivate = wp_spa_device_deactivate;
|
2020-01-30 17:41:25 +02:00
|
|
|
|
2020-06-10 15:34:34 -04:00
|
|
|
g_object_class_install_property (object_class, PROP_SPA_DEVICE_HANDLE,
|
|
|
|
|
g_param_spec_pointer ("spa-device-handle", "spa-device-handle",
|
|
|
|
|
"The spa device handle",
|
|
|
|
|
G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY | G_PARAM_STATIC_STRINGS));
|
2020-01-30 17:41:25 +02:00
|
|
|
|
2020-06-15 11:10:39 +03:00
|
|
|
g_object_class_install_property (object_class, PROP_PROPERTIES,
|
|
|
|
|
g_param_spec_boxed ("properties", "properties",
|
|
|
|
|
"Properties of the device", WP_TYPE_PROPERTIES,
|
|
|
|
|
G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY | G_PARAM_STATIC_STRINGS));
|
|
|
|
|
|
2020-01-30 17:41:25 +02:00
|
|
|
/**
|
2021-01-18 17:13:15 +02:00
|
|
|
* WpSpaDevice::create-object:
|
2020-01-30 17:41:25 +02:00
|
|
|
* @self: the #WpSpaDevice
|
|
|
|
|
* @id: the id of the managed object
|
2021-01-18 17:13:15 +02:00
|
|
|
* @type: the SPA type that the managed object should have
|
|
|
|
|
* @factory: the name of the SPA factory to use to construct the managed object
|
|
|
|
|
* @properties: additional properties that the managed object should have
|
2020-01-30 17:41:25 +02:00
|
|
|
*
|
2021-01-18 17:13:15 +02:00
|
|
|
* This signal is emitted when the device is creating a managed object
|
|
|
|
|
* The handler is expected to actually construct the object using the
|
|
|
|
|
* requested SPA @factory and with the given @properties.
|
|
|
|
|
* The handler should then store the object with
|
|
|
|
|
* wp_spa_device_store_managed_object(). The #WpSpaDevice will later unref
|
|
|
|
|
* the reference stored by this function when the managed object is to be
|
|
|
|
|
* destroyed.
|
2020-01-30 17:41:25 +02:00
|
|
|
*/
|
2021-01-18 17:13:15 +02:00
|
|
|
spa_device_signals[SIGNAL_CREATE_OBJECT] = g_signal_new (
|
|
|
|
|
"create-object", G_TYPE_FROM_CLASS (klass), G_SIGNAL_RUN_FIRST,
|
|
|
|
|
0, NULL, NULL, NULL, G_TYPE_NONE, 4, G_TYPE_UINT, G_TYPE_STRING,
|
|
|
|
|
G_TYPE_STRING, WP_TYPE_PROPERTIES);
|
2021-01-26 16:42:29 +02:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* WpSpaDevice::object-removed:
|
|
|
|
|
* @self: the #WpSpaDevice
|
|
|
|
|
* @id: the id of the managed object that was removed
|
|
|
|
|
*
|
|
|
|
|
* This signal is emitted when the device has deleted a managed object.
|
|
|
|
|
* The handler may optionally release additional resources associated
|
|
|
|
|
* with this object.
|
|
|
|
|
*
|
|
|
|
|
* It is not necessary to call wp_spa_device_store_managed_object()
|
|
|
|
|
* to remove the managed object, as this is done internally after this
|
|
|
|
|
* signal is fired.
|
|
|
|
|
*/
|
|
|
|
|
spa_device_signals[SIGNAL_OBJECT_REMOVED] = g_signal_new (
|
|
|
|
|
"object-removed", G_TYPE_FROM_CLASS (klass), G_SIGNAL_RUN_FIRST,
|
|
|
|
|
0, NULL, NULL, NULL, G_TYPE_NONE, 1, G_TYPE_UINT);
|
2020-01-30 17:41:25 +02:00
|
|
|
}
|
|
|
|
|
|
2020-06-10 15:34:34 -04:00
|
|
|
/**
|
|
|
|
|
* wp_spa_device_new_wrap:
|
|
|
|
|
* @core: the wireplumber core
|
|
|
|
|
* @spa_device_handle: the spa device handle
|
2020-06-15 11:10:39 +03:00
|
|
|
* @properties: (nullable) (transfer full): additional properties of the device
|
2020-06-10 15:34:34 -04:00
|
|
|
*
|
|
|
|
|
* Returns: (transfer full): A new #WpSpaDevice
|
|
|
|
|
*/
|
|
|
|
|
WpSpaDevice *
|
2020-06-15 11:10:39 +03:00
|
|
|
wp_spa_device_new_wrap (WpCore * core, gpointer spa_device_handle,
|
|
|
|
|
WpProperties * properties)
|
2020-06-10 15:34:34 -04:00
|
|
|
{
|
2020-06-15 11:10:39 +03:00
|
|
|
g_autoptr (WpProperties) props = properties;
|
2020-06-10 15:34:34 -04:00
|
|
|
return g_object_new (WP_TYPE_SPA_DEVICE,
|
|
|
|
|
"core", core,
|
|
|
|
|
"spa-device-handle", spa_device_handle,
|
2020-06-15 11:10:39 +03:00
|
|
|
"properties", props,
|
2020-06-10 15:34:34 -04:00
|
|
|
NULL);
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-30 17:41:25 +02:00
|
|
|
/**
|
|
|
|
|
* wp_spa_device_new_from_spa_factory:
|
|
|
|
|
* @core: the wireplumber core
|
|
|
|
|
* @factory_name: the name of the SPA factory
|
|
|
|
|
* @properties: (nullable) (transfer full): properties to be passed to device
|
|
|
|
|
* constructor
|
|
|
|
|
*
|
|
|
|
|
* Constructs a `SPA_TYPE_INTERFACE_Device` by loading the given SPA
|
|
|
|
|
* @factory_name.
|
|
|
|
|
*
|
|
|
|
|
* To export this device to the PipeWire server, you need to call
|
2021-01-18 17:13:15 +02:00
|
|
|
* wp_object_activate() requesting %WP_PROXY_FEATURE_BOUND and
|
2020-01-30 17:41:25 +02:00
|
|
|
* wait for the operation to complete.
|
|
|
|
|
*
|
|
|
|
|
* Returns: (nullable) (transfer full): A new #WpSpaDevice wrapping the
|
|
|
|
|
* device that was constructed by the factory, or %NULL if the factory
|
|
|
|
|
* does not exist or was unable to construct the device
|
|
|
|
|
*/
|
|
|
|
|
WpSpaDevice *
|
|
|
|
|
wp_spa_device_new_from_spa_factory (WpCore * core,
|
|
|
|
|
const gchar * factory_name, WpProperties * properties)
|
|
|
|
|
{
|
|
|
|
|
g_autoptr (WpProperties) props = properties;
|
|
|
|
|
struct pw_context *pw_context = wp_core_get_pw_context (core);
|
2020-06-10 15:34:34 -04:00
|
|
|
struct spa_handle *handle = NULL;
|
2020-01-30 17:41:25 +02:00
|
|
|
|
|
|
|
|
g_return_val_if_fail (pw_context != NULL, NULL);
|
|
|
|
|
|
|
|
|
|
/* Load the monitor handle */
|
2020-06-10 15:34:34 -04:00
|
|
|
handle = pw_context_load_spa_handle (pw_context, factory_name,
|
|
|
|
|
props ? wp_properties_peek_dict (props) : NULL);
|
|
|
|
|
if (!handle) {
|
|
|
|
|
wp_warning ("SPA handle '%s' could not be loaded; is it installed?",
|
|
|
|
|
factory_name);
|
2020-01-30 17:41:25 +02:00
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2020-06-15 11:10:39 +03:00
|
|
|
return wp_spa_device_new_wrap (core, handle, g_steal_pointer (&props));
|
2020-06-10 15:34:34 -04:00
|
|
|
}
|
2020-01-30 17:41:25 +02:00
|
|
|
|
2021-01-18 17:13:15 +02:00
|
|
|
/**
|
|
|
|
|
* wp_spa_device_get_properties:
|
|
|
|
|
* @self: the spa device
|
|
|
|
|
*
|
|
|
|
|
* Returns: (transfer full): the device properties
|
|
|
|
|
*/
|
|
|
|
|
WpProperties *
|
|
|
|
|
wp_spa_device_get_properties (WpSpaDevice * self)
|
2020-06-10 15:34:34 -04:00
|
|
|
{
|
2021-01-18 17:13:15 +02:00
|
|
|
g_return_val_if_fail (WP_IS_SPA_DEVICE (self), NULL);
|
|
|
|
|
return wp_properties_ref (self->properties);
|
2020-06-10 15:34:34 -04:00
|
|
|
}
|
|
|
|
|
|
2021-01-18 17:13:15 +02:00
|
|
|
/**
|
|
|
|
|
* wp_spa_device_get_managed_object:
|
|
|
|
|
* @self: the spa device
|
|
|
|
|
* @id: the (device-internal) id of the object to get
|
|
|
|
|
*
|
|
|
|
|
* Returns: (transfer full): the managed object associated with @id
|
|
|
|
|
*/
|
|
|
|
|
GObject *
|
|
|
|
|
wp_spa_device_get_managed_object (WpSpaDevice * self, guint id)
|
2020-06-10 15:34:34 -04:00
|
|
|
{
|
2021-01-18 17:13:15 +02:00
|
|
|
g_return_val_if_fail (WP_IS_SPA_DEVICE (self), NULL);
|
2020-06-10 15:34:34 -04:00
|
|
|
|
2021-01-18 17:13:15 +02:00
|
|
|
GObject *ret = (id < self->managed_objs->len) ?
|
|
|
|
|
g_ptr_array_index (self->managed_objs, id) : NULL;
|
|
|
|
|
return ret ? g_object_ref (ret) : ret;
|
2020-06-10 15:34:34 -04:00
|
|
|
}
|
|
|
|
|
|
2021-01-18 17:13:15 +02:00
|
|
|
/**
|
|
|
|
|
* wp_spa_device_store_managed_object:
|
|
|
|
|
* @self: the spa device
|
|
|
|
|
* @id: the (device-internal) id of the object
|
|
|
|
|
* @object: (transfer full) (nullable): the object to store or %NULL to remove
|
|
|
|
|
* the managed object associated with @id
|
|
|
|
|
*/
|
2020-06-10 15:34:34 -04:00
|
|
|
void
|
2021-01-18 17:13:15 +02:00
|
|
|
wp_spa_device_store_managed_object (WpSpaDevice * self, guint id,
|
|
|
|
|
GObject * object)
|
2020-06-10 15:34:34 -04:00
|
|
|
{
|
|
|
|
|
g_return_if_fail (WP_IS_SPA_DEVICE (self));
|
|
|
|
|
|
2021-01-18 17:13:15 +02:00
|
|
|
if (id >= self->managed_objs->len)
|
|
|
|
|
g_ptr_array_set_size (self->managed_objs, id + 1);
|
2020-06-10 15:34:34 -04:00
|
|
|
|
2021-01-18 17:13:15 +02:00
|
|
|
/* replace the item at @id; g_ptr_array_insert is tempting to use here
|
|
|
|
|
instead, but it's wrong because it will not remove the previous item */
|
|
|
|
|
gpointer *ptr = &g_ptr_array_index (self->managed_objs, id);
|
|
|
|
|
if (*ptr)
|
|
|
|
|
g_object_unref (*ptr);
|
|
|
|
|
*ptr = object;
|
2020-01-30 17:41:25 +02:00
|
|
|
}
|