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-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"
|
2021-05-06 15:45:13 +03:00
|
|
|
#include "log.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
|
|
|
|
log: implement a log topics system, like pipewire
The intention is to make checks for enabled log topics faster.
Every topic has its own structure that is statically defined in the file
where the logs are printed from. The structure is initialized transparently
when it is first used and it contains all the log level flags for the levels
that this topic should print messages. It is then checked on the wp_log()
macro before printing the message.
Topics from SPA/PipeWire are also handled natively, so messages are printed
directly without checking if the topic is enabled, since the PipeWire and SPA
macros do the checking themselves.
Messages coming from GLib are checked inside the handler.
An internal WpLogFields object is used to manage the state of each log
message, populating all the fields appropriately from the place they
are coming from (wp_log, spa_log, glib log), formatting the message and
then printing it. For printing to the journald, we still use the glib
message handler, converting all the needed fields to GLogField on demand.
That message handler does not do any checks for the topic or the level, so
we can just call it to send the message.
2023-05-16 11:51:29 +03:00
|
|
|
WP_DEFINE_LOCAL_LOG_TOPIC ("wp-device")
|
|
|
|
|
|
2021-05-21 18:40:43 +03:00
|
|
|
/*! \defgroup wpdevice WpDevice */
|
2021-05-13 17:54:58 +03:00
|
|
|
/*!
|
2021-05-21 18:40:43 +03:00
|
|
|
* \struct 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.
|
|
|
|
|
*
|
2021-05-13 17:54:58 +03:00
|
|
|
*/
|
2021-05-21 18:40:43 +03: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
|
|
|
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
|
2021-05-12 13:52:02 -04:00
|
|
|
static void
|
|
|
|
|
wp_device_pw_proxy_destroyed (WpProxy * proxy)
|
|
|
|
|
{
|
|
|
|
|
wp_pw_object_mixin_handle_pw_proxy_destroyed (proxy);
|
|
|
|
|
|
|
|
|
|
WP_PROXY_CLASS (wp_device_parent_class)->pw_proxy_destroyed (proxy);
|
|
|
|
|
}
|
|
|
|
|
|
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;
|
2021-05-12 13:52:02 -04:00
|
|
|
proxy_class->pw_proxy_destroyed = wp_device_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);
|
2021-06-03 08:58:15 -04:00
|
|
|
g_autoptr (WpSpaPod) p = param;
|
2020-11-25 14:02:33 +02:00
|
|
|
return pw_device_set_param (d->iface, id, flags,
|
2021-06-03 08:58:15 -04:00
|
|
|
wp_spa_pod_get_spa_pod (p));
|
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
|
|
|
|
2021-05-13 17:54:58 +03:00
|
|
|
/*!
|
2021-05-21 18:40:43 +03:00
|
|
|
* \brief Constructs a device on the PipeWire server by asking the remote
|
|
|
|
|
* factory \a factory_name to create it.
|
2020-01-30 17:41:25 +02:00
|
|
|
*
|
|
|
|
|
* 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.
|
|
|
|
|
*
|
2021-05-21 18:40:43 +03:00
|
|
|
* \ingroup wpdevice
|
|
|
|
|
* \param core the wireplumber core
|
|
|
|
|
* \param factory_name the pipewire factory name to construct the device
|
|
|
|
|
* \param properties (nullable) (transfer full): the properties to pass to the
|
|
|
|
|
* factory
|
|
|
|
|
* \returns (nullable) (transfer full): the new device or %NULL if the core
|
2020-01-30 17:41:25 +02:00
|
|
|
* is not connected and therefore the device cannot be created
|
|
|
|
|
*/
|
2021-05-13 17:54:58 +03:00
|
|
|
|
2020-01-30 17:41:25 +02:00
|
|
|
WpDevice *
|
|
|
|
|
wp_device_new_from_factory (WpCore * core,
|
|
|
|
|
const gchar * factory_name, WpProperties * properties)
|
|
|
|
|
{
|
|
|
|
|
g_autoptr (WpProperties) props = properties;
|
2021-05-17 11:08:04 -04:00
|
|
|
return g_object_new (WP_TYPE_DEVICE,
|
|
|
|
|
"core", core,
|
|
|
|
|
"factory-name", factory_name,
|
|
|
|
|
"global-properties", props,
|
|
|
|
|
NULL);
|
2020-01-30 17:41:25 +02:00
|
|
|
}
|
|
|
|
|
|
2021-05-21 18:40:43 +03:00
|
|
|
/*! \defgroup wpspadevice WpSpaDevice */
|
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;
|
2024-12-15 15:48:53 +02:00
|
|
|
GPtrArray *pending_obj_config;
|
2020-01-30 17:41:25 +02:00
|
|
|
};
|
|
|
|
|
|
2021-05-21 18:40:43 +03:00
|
|
|
enum {
|
|
|
|
|
PROP_0,
|
|
|
|
|
PROP_SPA_DEVICE_HANDLE,
|
|
|
|
|
PROP_PROPERTIES,
|
|
|
|
|
};
|
|
|
|
|
|
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 };
|
|
|
|
|
|
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
|
|
|
|
2024-12-15 15:48:53 +02:00
|
|
|
static void
|
|
|
|
|
pod_unref_safe (gpointer object)
|
|
|
|
|
{
|
|
|
|
|
if (object)
|
|
|
|
|
wp_spa_pod_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);
|
2024-12-15 15:48:53 +02:00
|
|
|
self->pending_obj_config = g_ptr_array_new_with_free_func (pod_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);
|
2024-12-15 15:48:53 +02:00
|
|
|
g_clear_pointer (&self->pending_obj_config, 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);
|
|
|
|
|
|
|
|
|
|
/*
|
2024-11-07 21:49:33 +00:00
|
|
|
* This is emitted synchronously at the time we add the listener and
|
|
|
|
|
* before object_info is emitted. It gives us additional properties
|
2020-01-30 17:41:25 +02:00
|
|
|
* 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);
|
|
|
|
|
}
|
|
|
|
|
|
2024-12-15 15:48:53 +02:00
|
|
|
static WpSpaPod *
|
|
|
|
|
pending_obj_config_pop (WpSpaDevice *self, guint32 id)
|
|
|
|
|
{
|
|
|
|
|
if (id < self->pending_obj_config->len)
|
|
|
|
|
return g_steal_pointer (&g_ptr_array_index (self->pending_obj_config, id));
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
pending_obj_config_set (WpSpaDevice *self, guint32 id, WpSpaPod *props)
|
|
|
|
|
{
|
|
|
|
|
if (id >= self->pending_obj_config->len)
|
|
|
|
|
g_ptr_array_set_size (self->pending_obj_config, id + 1);
|
|
|
|
|
|
|
|
|
|
gpointer *ptr = &g_ptr_array_index (self->pending_obj_config, id);
|
|
|
|
|
pod_unref_safe (*ptr);
|
|
|
|
|
*ptr = props;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
append_props (WpSpaPodBuilder *b, WpSpaPod *props, GHashTable *used)
|
|
|
|
|
{
|
|
|
|
|
g_autoptr (WpIterator) it = wp_spa_pod_new_iterator (props);
|
|
|
|
|
GValue next = G_VALUE_INIT;
|
|
|
|
|
|
2024-12-20 19:15:21 +02:00
|
|
|
for (; wp_iterator_next (it, &next); g_value_unset (&next)) {
|
2024-12-15 15:48:53 +02:00
|
|
|
WpSpaPod *p = g_value_get_boxed (&next);
|
|
|
|
|
const char *key;
|
|
|
|
|
g_autoptr (WpSpaPod) value = NULL;
|
|
|
|
|
|
|
|
|
|
if (!wp_spa_pod_get_property (p, &key, &value))
|
|
|
|
|
continue;
|
|
|
|
|
if (g_hash_table_contains(used, key))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
wp_spa_pod_builder_add_property (b, key);
|
|
|
|
|
wp_spa_pod_builder_add_pod (b, value);
|
|
|
|
|
|
2024-12-20 19:15:21 +02:00
|
|
|
g_hash_table_add (used, (gpointer) g_strdup (key));
|
2024-12-15 15:48:53 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static WpSpaPod *
|
|
|
|
|
merge_props (WpSpaPod *old_props, WpSpaPod *new_props)
|
|
|
|
|
{
|
2024-12-20 19:15:21 +02:00
|
|
|
g_autoptr (GHashTable) used = g_hash_table_new_full (g_str_hash, g_str_equal, g_free, NULL);
|
2024-12-15 15:48:53 +02:00
|
|
|
g_autoptr (WpSpaPodBuilder) b = wp_spa_pod_builder_new_object (
|
|
|
|
|
"Spa:Pod:Object:Param:Props", "Props");
|
|
|
|
|
|
|
|
|
|
if (new_props) {
|
|
|
|
|
append_props (b, new_props, used);
|
|
|
|
|
wp_spa_pod_unref (new_props);
|
|
|
|
|
}
|
|
|
|
|
if (old_props) {
|
|
|
|
|
append_props (b, old_props, used);
|
|
|
|
|
wp_spa_pod_unref (old_props);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return wp_spa_pod_builder_end (b);
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
2024-12-15 15:48:53 +02:00
|
|
|
if (!g_strcmp0 (type, "ObjectConfig") && props) {
|
|
|
|
|
if (child && WP_IS_PIPEWIRE_OBJECT (child)) {
|
|
|
|
|
wp_pipewire_object_set_param (WP_PIPEWIRE_OBJECT (child), "Props", 0,
|
|
|
|
|
g_steal_pointer (&props));
|
|
|
|
|
} else if (!child) {
|
|
|
|
|
/* Save Props set on ids pending for a managed object */
|
|
|
|
|
WpSpaPod *pending_props = pending_obj_config_pop (self, id);
|
|
|
|
|
if (pending_props) {
|
|
|
|
|
pending_props = merge_props (pending_props, g_steal_pointer(&props));
|
|
|
|
|
pending_obj_config_set (self, id, pending_props);
|
|
|
|
|
}
|
|
|
|
|
}
|
2021-01-20 16:46:55 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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);
|
|
|
|
|
|
2024-05-31 17:04:18 +03:00
|
|
|
wp_debug_object (self, "object info: id:%u type:%s factory:%s",
|
|
|
|
|
id, type, info->factory_name);
|
|
|
|
|
|
|
|
|
|
if (id < self->managed_objs->len &&
|
|
|
|
|
g_ptr_array_index (self->managed_objs, id) != NULL) {
|
|
|
|
|
wp_debug_object (self, "object already exists, removing");
|
|
|
|
|
g_signal_emit (self, spa_device_signals[SIGNAL_OBJECT_REMOVED], 0, id);
|
|
|
|
|
wp_spa_device_store_managed_object (self, id, NULL);
|
|
|
|
|
}
|
|
|
|
|
|
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 {
|
2024-05-31 17:04:18 +03:00
|
|
|
wp_debug_object (self, "object removed: id:%u", id);
|
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);
|
2024-12-15 15:48:53 +02:00
|
|
|
g_ptr_array_set_size (self->pending_obj_config, 0);
|
2021-01-18 17:13:15 +02:00
|
|
|
wp_object_update_features (object, 0, WP_SPA_DEVICE_FEATURE_ENABLED);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-05-21 18:40:43 +03:00
|
|
|
/*!
|
|
|
|
|
* \struct 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.
|
|
|
|
|
*
|
|
|
|
|
* 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.
|
|
|
|
|
*
|
|
|
|
|
* \gproperties
|
|
|
|
|
*
|
|
|
|
|
* \gproperty{properties, WpProperties *, G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY,
|
|
|
|
|
* Properties of the spa device}
|
|
|
|
|
*
|
|
|
|
|
* \gproperty{spa-device-handle, gpointer, G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY,
|
|
|
|
|
* The spa device handle}
|
|
|
|
|
*
|
|
|
|
|
* \gsignals
|
|
|
|
|
*
|
|
|
|
|
* \par create-object
|
|
|
|
|
* \parblock
|
|
|
|
|
* \code
|
|
|
|
|
* void
|
|
|
|
|
* create_object_callback (WpSpaDevice * self,
|
|
|
|
|
* guint id,
|
|
|
|
|
* gchar * type,
|
|
|
|
|
* gchar * factory,
|
|
|
|
|
* WpProperties * properties,
|
|
|
|
|
* gpointer user_data)
|
|
|
|
|
* \endcode
|
|
|
|
|
*
|
|
|
|
|
* 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.
|
|
|
|
|
*
|
|
|
|
|
* Parameters:
|
|
|
|
|
* - `id` - the id of the managed object
|
|
|
|
|
* - `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
|
|
|
|
|
*
|
|
|
|
|
* Flags: G_SIGNAL_RUN_FIRST
|
|
|
|
|
* \endparblock
|
|
|
|
|
*
|
2021-11-17 14:09:03 +10:00
|
|
|
* \par object-removed
|
2021-05-21 18:40:43 +03:00
|
|
|
* \parblock
|
|
|
|
|
* \code
|
|
|
|
|
* void
|
|
|
|
|
* object_removed_callback (WpSpaDevice * self,
|
|
|
|
|
* guint id,
|
|
|
|
|
* gpointer user_data)
|
|
|
|
|
* \endcode
|
|
|
|
|
*
|
|
|
|
|
* 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.
|
|
|
|
|
*
|
|
|
|
|
* Parameters:
|
|
|
|
|
* - `id` - the id of the managed object
|
|
|
|
|
*
|
|
|
|
|
* Flags: G_SIGNAL_RUN_FIRST
|
|
|
|
|
* \endparblock
|
|
|
|
|
*/
|
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));
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
|
2021-05-13 17:54:58 +03:00
|
|
|
/*!
|
2021-06-01 19:39:13 -04:00
|
|
|
* \brief Constructs an SPA Device object from an existing device handle.
|
|
|
|
|
*
|
2021-05-21 18:40:43 +03:00
|
|
|
* \ingroup wpspadevice
|
|
|
|
|
* \param core the wireplumber core
|
|
|
|
|
* \param spa_device_handle the spa device handle
|
|
|
|
|
* \param properties (nullable) (transfer full): additional properties of the device
|
|
|
|
|
* \returns (transfer full): A new WpSpaDevice
|
2020-06-10 15:34:34 -04:00
|
|
|
*/
|
|
|
|
|
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);
|
|
|
|
|
}
|
|
|
|
|
|
2021-05-13 17:54:58 +03:00
|
|
|
/*!
|
2021-05-21 18:40:43 +03:00
|
|
|
* \brief Constructs a `SPA_TYPE_INTERFACE_Device` by loading the given SPA
|
|
|
|
|
* \a factory_name.
|
2020-01-30 17:41:25 +02:00
|
|
|
*
|
|
|
|
|
* To export this device to the PipeWire server, you need to call
|
2021-05-21 18:40:43 +03:00
|
|
|
* wp_object_activate() requesting WP_PROXY_FEATURE_BOUND and
|
2020-01-30 17:41:25 +02:00
|
|
|
* wait for the operation to complete.
|
|
|
|
|
*
|
2021-05-21 18:40:43 +03:00
|
|
|
* \ingroup wpspadevice
|
|
|
|
|
* \param core the wireplumber core
|
|
|
|
|
* \param factory_name the name of the SPA factory
|
|
|
|
|
* \param properties (nullable) (transfer full): properties to be passed to device
|
|
|
|
|
* constructor
|
|
|
|
|
* \returns (nullable) (transfer full): A new WpSpaDevice wrapping the
|
|
|
|
|
* device that was constructed by the factory, or NULL if the factory
|
2020-01-30 17:41:25 +02:00
|
|
|
* 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) {
|
2023-05-18 16:19:49 +03:00
|
|
|
wp_notice ("SPA handle '%s' could not be loaded; is it installed?",
|
2020-06-10 15:34:34 -04:00
|
|
|
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-05-13 17:54:58 +03:00
|
|
|
/*!
|
2021-06-01 19:39:13 -04:00
|
|
|
* \brief Gets the properties of this device.
|
|
|
|
|
*
|
2021-05-21 18:40:43 +03:00
|
|
|
* \ingroup wpspadevice
|
|
|
|
|
* \param self the spa device
|
|
|
|
|
* \returns (transfer full): the device properties
|
2021-01-18 17:13:15 +02:00
|
|
|
*/
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
|
2022-06-16 15:27:31 -04:00
|
|
|
/*!
|
|
|
|
|
* \brief Iterates through all the objects managed by this device.
|
|
|
|
|
*
|
|
|
|
|
* \ingroup wpspadevice
|
|
|
|
|
* \param self the spa device
|
|
|
|
|
* \returns (transfer full): a WpIterator that iterates over all the objects
|
|
|
|
|
* managed by this device
|
|
|
|
|
* \since 0.4.11
|
|
|
|
|
*/
|
|
|
|
|
WpIterator *
|
|
|
|
|
wp_spa_device_new_managed_object_iterator (WpSpaDevice * self)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail (WP_IS_SPA_DEVICE (self), NULL);
|
|
|
|
|
return wp_iterator_new_ptr_array (g_ptr_array_ref (self->managed_objs),
|
|
|
|
|
G_TYPE_OBJECT);
|
|
|
|
|
}
|
|
|
|
|
|
2021-05-13 17:54:58 +03:00
|
|
|
/*!
|
2021-06-01 19:39:13 -04:00
|
|
|
* \brief Gets one of the objects managed by this device.
|
|
|
|
|
*
|
2021-05-21 18:40:43 +03:00
|
|
|
* \ingroup wpspadevice
|
|
|
|
|
* \param self the spa device
|
|
|
|
|
* \param id the (device-internal) id of the object to get
|
|
|
|
|
* \returns (transfer full): the managed object associated with \a id
|
2021-01-18 17:13:15 +02:00
|
|
|
*/
|
|
|
|
|
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-05-13 17:54:58 +03:00
|
|
|
/*!
|
2021-06-01 19:39:13 -04:00
|
|
|
* \brief Stores or removes a managed object into/from a device.
|
|
|
|
|
*
|
2021-05-21 18:40:43 +03:00
|
|
|
* \ingroup wpspadevice
|
|
|
|
|
* \param self the spa device
|
|
|
|
|
* \param id the (device-internal) id of the object
|
|
|
|
|
* \param object (transfer full) (nullable): the object to store or NULL to remove
|
|
|
|
|
* the managed object associated with \a id
|
2021-01-18 17:13:15 +02:00
|
|
|
*/
|
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-05-13 17:54:58 +03:00
|
|
|
/* replace the item at @em id; g_ptr_array_insert is tempting to use here
|
2021-01-18 17:13:15 +02:00
|
|
|
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;
|
2024-12-15 15:48:53 +02:00
|
|
|
|
|
|
|
|
/* Clear pending status, and set pending props if any */
|
|
|
|
|
g_autoptr(WpSpaPod) props = pending_obj_config_pop (self, id);
|
|
|
|
|
|
|
|
|
|
if (props && object && WP_IS_PIPEWIRE_OBJECT (object)) {
|
|
|
|
|
wp_trace_boxed (WP_TYPE_SPA_POD, props, "pending ObjectConfig, object %d", id);
|
|
|
|
|
wp_pipewire_object_set_param (WP_PIPEWIRE_OBJECT (object), "Props", 0,
|
|
|
|
|
g_steal_pointer (&props));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*!
|
|
|
|
|
* \brief Marks a managed object id pending.
|
|
|
|
|
*
|
|
|
|
|
* When an object id is pending, Props from received ObjectConfig events
|
|
|
|
|
* for the id are saved. When \ref wp_spa_device_store_managed_object later sets
|
|
|
|
|
* an object for the id, the saved Props are immediately set on the object and
|
|
|
|
|
* pending status is cleared.
|
|
|
|
|
*
|
|
|
|
|
* If an object is already set for the id, this has no effect.
|
|
|
|
|
*
|
|
|
|
|
* \ingroup wpspadevice
|
|
|
|
|
* \param self the spa device
|
|
|
|
|
* \param id the (device-internal) id of the object
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
wp_spa_device_set_managed_pending (WpSpaDevice * self, guint id)
|
|
|
|
|
{
|
|
|
|
|
g_return_if_fail (WP_IS_SPA_DEVICE (self));
|
|
|
|
|
|
|
|
|
|
g_autoptr (GObject) obj = wp_spa_device_get_managed_object (self, id);
|
|
|
|
|
if (obj)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
pending_obj_config_set (self, id,
|
|
|
|
|
wp_spa_pod_new_object ("Spa:Pod:Object:Param:Props", "Props", NULL));
|
2020-01-30 17:41:25 +02:00
|
|
|
}
|