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-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"
|
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
|
|
|
|
2021-05-13 17:54:58 +03:00
|
|
|
/*!
|
|
|
|
|
* @brief
|
|
|
|
|
* @em parent
|
|
|
|
|
*/
|
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
|
|
|
|
2021-05-13 17:54:58 +03:00
|
|
|
/*!
|
|
|
|
|
* @file device.c
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/*!
|
|
|
|
|
* @struct WpDevice
|
|
|
|
|
* @section device_section Pipewire 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
|
|
|
*
|
2021-05-13 17:54:58 +03:00
|
|
|
* @brief The [WpDevice](@ref device_section) class allows accessing the properties and methods of a
|
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
|
|
|
* PipeWire device object (`struct pw_device`).
|
|
|
|
|
*
|
2021-05-13 17:54:58 +03:00
|
|
|
* A [WpDevice](@ref device_section) is constructed internally when a new device appears on the
|
|
|
|
|
* PipeWire registry and it is made available through the [WpObjectManager](@ref object_manager_section) API.
|
|
|
|
|
* Alternatively, a [WpDevice](@ref device_section) can also be constructed using
|
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_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
|
|
|
*
|
|
|
|
|
* @section spa_device_section WpSpaDevice
|
|
|
|
|
*
|
|
|
|
|
* @brief A [WpSpaDevice](@ref spa_device_section) 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.
|
|
|
|
|
*
|
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-05-13 17:54:58 +03:00
|
|
|
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
G_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);
|
|
|
|
|
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
|
|
|
|
2021-05-13 17:54:58 +03:00
|
|
|
/*!
|
|
|
|
|
* @memberof 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
|
2020-01-30 17:41:25 +02:00
|
|
|
*
|
2021-05-13 17:54:58 +03:00
|
|
|
* @brief Constructs a device on the PipeWire server by asking the remote factory
|
|
|
|
|
* @em 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-13 17:54:58 +03:00
|
|
|
* @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-13 17:54:58 +03:00
|
|
|
/*!
|
|
|
|
|
* @memberof WpDevice
|
|
|
|
|
* @props @b properties
|
|
|
|
|
*
|
|
|
|
|
* @code
|
|
|
|
|
* "properties" WpProperties *
|
|
|
|
|
* @endcode
|
|
|
|
|
*
|
|
|
|
|
* @brief Flags : Read / Write / Construct Only
|
|
|
|
|
*
|
|
|
|
|
* @props @b spa-device-handle
|
|
|
|
|
*
|
|
|
|
|
* @code
|
|
|
|
|
* "spa-device-handle" gpointer *
|
|
|
|
|
* @endcode
|
|
|
|
|
*
|
|
|
|
|
* @brief Flags : Read / Write / Construct Only
|
|
|
|
|
*/
|
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
|
|
|
};
|
|
|
|
|
|
2021-05-13 17:54:58 +03:00
|
|
|
/*!
|
|
|
|
|
* @memberof WpDevice
|
|
|
|
|
* @signal @b create-object
|
|
|
|
|
*
|
|
|
|
|
* @code
|
|
|
|
|
* create_object_callback (WpSpaDevice * self,
|
|
|
|
|
* guint id,
|
|
|
|
|
* gchar * type,
|
|
|
|
|
* gchar * factory,
|
|
|
|
|
* WpProperties * properties,
|
|
|
|
|
* gpointer user_data)
|
|
|
|
|
* @endcode
|
|
|
|
|
*
|
|
|
|
|
* @brief 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.
|
|
|
|
|
*
|
|
|
|
|
* Params:
|
|
|
|
|
* @arg self - the [WpSpaDevice](@ref spa_device_section)
|
|
|
|
|
* @arg id - the id of the managed object
|
|
|
|
|
* @arg type - the SPA type that the managed object should have
|
|
|
|
|
* @arg factory - the name of the SPA factory to use to construct the managed object
|
|
|
|
|
* @arg properties - additional properties that the managed object should have
|
|
|
|
|
* @arg user_data
|
|
|
|
|
*
|
|
|
|
|
* Flags: Run First
|
|
|
|
|
*
|
|
|
|
|
* @signal @b remove-object
|
|
|
|
|
*
|
|
|
|
|
* @code
|
|
|
|
|
* object_removed_callback (WpSpaDevice * self,
|
|
|
|
|
* guint id,
|
|
|
|
|
* gpointer user_data)
|
|
|
|
|
* @endcode
|
|
|
|
|
*
|
|
|
|
|
* @brief 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.
|
|
|
|
|
*
|
|
|
|
|
* Params:
|
|
|
|
|
* @arg self - the [WpSpaDevice](@ref spa_device_section)
|
|
|
|
|
* @arg id - the id of the managed object
|
|
|
|
|
* @arg user_data
|
|
|
|
|
*
|
|
|
|
|
* Flags: Run First
|
|
|
|
|
*
|
|
|
|
|
*/
|
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
|
|
|
|
|
|
|
|
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);
|
|
|
|
|
|
2021-04-28 20:46:08 +03:00
|
|
|
wp_proxy_watch_bind_error (WP_PROXY (self), WP_TRANSITION (transition));
|
2021-01-18 17:13:15 +02:00
|
|
|
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));
|
|
|
|
|
|
2021-05-13 17:54:58 +03:00
|
|
|
/*
|
2021-01-18 17:13:15 +02:00
|
|
|
* WpSpaDevice::create-object:
|
2021-05-13 17:54:58 +03:00
|
|
|
* @self: the [WpSpaDevice](@ref spa_device_section)
|
2020-01-30 17:41:25 +02:00
|
|
|
* @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-05-13 17:54:58 +03:00
|
|
|
* @brief This signal is emitted when the device is creating a managed object
|
2021-01-18 17:13:15 +02:00
|
|
|
* The handler is expected to actually construct the object using the
|
2021-05-13 17:54:58 +03:00
|
|
|
* requested SPA @em factory and with the given @em properties.
|
2021-01-18 17:13:15 +02:00
|
|
|
* The handler should then store the object with
|
2021-05-13 17:54:58 +03:00
|
|
|
* wp_spa_device_store_managed_object(). The [WpSpaDevice](@ref spa_device_section) will later unref
|
2021-01-18 17:13:15 +02:00
|
|
|
* 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
|
|
|
|
2021-05-13 17:54:58 +03:00
|
|
|
/*
|
2021-01-26 16:42:29 +02:00
|
|
|
* WpSpaDevice::object-removed:
|
2021-05-13 17:54:58 +03:00
|
|
|
* @self: the [WpSpaDevice](@ref spa_device_section)
|
2021-01-26 16:42:29 +02:00
|
|
|
* @id: the id of the managed object that was removed
|
|
|
|
|
*
|
2021-05-13 17:54:58 +03:00
|
|
|
* @brief This signal is emitted when the device has deleted a managed object.
|
2021-01-26 16:42:29 +02:00
|
|
|
* 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
|
|
|
}
|
|
|
|
|
|
2021-05-13 17:54:58 +03:00
|
|
|
/*!
|
|
|
|
|
* @memberof WpDevice
|
|
|
|
|
* @param core: the wireplumber core
|
|
|
|
|
* @param spa_device_handle: the spa device handle
|
|
|
|
|
* @param properties: (nullable) (transfer full): additional properties of the device
|
2020-06-10 15:34:34 -04:00
|
|
|
*
|
2021-05-13 17:54:58 +03:00
|
|
|
* @returns (transfer full): A new [WpSpaDevice](@ref spa_device_section)
|
2020-06-10 15:34:34 -04:00
|
|
|
*/
|
2021-05-13 17:54:58 +03:00
|
|
|
|
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
|
|
|
/*!
|
|
|
|
|
* @memberof WpDevice
|
|
|
|
|
* @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
|
2020-01-30 17:41:25 +02:00
|
|
|
* constructor
|
|
|
|
|
*
|
2021-05-13 17:54:58 +03:00
|
|
|
* @brief Constructs a `SPA_TYPE_INTERFACE_Device` by loading the given SPA
|
|
|
|
|
* @em factory_name.
|
2020-01-30 17:41:25 +02:00
|
|
|
*
|
|
|
|
|
* 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.
|
|
|
|
|
*
|
2021-05-13 17:54:58 +03:00
|
|
|
* @returns (nullable) (transfer full): A new [WpSpaDevice](@ref spa_device_section) wrapping the
|
2020-01-30 17:41:25 +02:00
|
|
|
* device that was constructed by the factory, or %NULL if the factory
|
|
|
|
|
* does not exist or was unable to construct the device
|
|
|
|
|
*/
|
2021-05-13 17:54:58 +03:00
|
|
|
|
2020-01-30 17:41:25 +02:00
|
|
|
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-05-13 17:54:58 +03:00
|
|
|
/*!
|
|
|
|
|
* @memberof WpDevice
|
|
|
|
|
* @param self: the spa device
|
2021-01-18 17:13:15 +02:00
|
|
|
*
|
2021-05-13 17:54:58 +03:00
|
|
|
* @returns (transfer full): the device properties
|
2021-01-18 17:13:15 +02:00
|
|
|
*/
|
2021-05-13 17:54:58 +03:00
|
|
|
|
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
|
|
|
}
|
|
|
|
|
|
2021-05-13 17:54:58 +03:00
|
|
|
/*!
|
|
|
|
|
* @memberof WpDevice
|
|
|
|
|
* @param self: the spa device
|
|
|
|
|
* @param id: the (device-internal) id of the object to get
|
2021-01-18 17:13:15 +02:00
|
|
|
*
|
2021-05-13 17:54:58 +03:00
|
|
|
* @returns (transfer full): the managed object associated with @em id
|
2021-01-18 17:13:15 +02:00
|
|
|
*/
|
2021-05-13 17:54:58 +03:00
|
|
|
|
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
|
|
|
/*!
|
|
|
|
|
* @memberof WpDevice
|
|
|
|
|
* @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 @em id
|
2021-01-18 17:13:15 +02:00
|
|
|
*/
|
2021-05-13 17:54:58 +03: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;
|
2020-01-30 17:41:25 +02:00
|
|
|
}
|