fdo-mirrors/wireplumber
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/pipewire/wireplumber.git synced 2025-12-20 12:20:04 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
wireplumber/lib/wp/link.c

304 lines
8.9 KiB
C
Raw Normal View History

proxy-link: add new API
2019-07-05 10:22:28 -04:00
/* WirePlumber
*
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
* Copyright © 2019-2020 Collabora Ltd.
proxy-link: add new API
2019-07-05 10:22:28 -04:00
* @author Julian Bouzas <julian.bouzas@collabora.com>
*
* SPDX-License-Identifier: MIT
*/
lib: drop the proxy- prefix from client, device, link, port & node
2020-01-22 18:54:45 +02:00
#include "link.h"
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
#include "log.h"
link: add link state accessors and change signal
2022-05-26 15:42:45 +03:00
#include "wpenums.h"
lib: refactor WpProxy This is an attempt to unclutter the API of WpProxy and split functionality into smaller pieces, making it easier to work with. In this new class layout, we have the following classes: - WpObject: base class for everything; handles activating | and deactivating "features" |- WpProxy: base class for anything that wraps a pw_proxy; | handles events from pw_proxy and nothing more |- WpGlobalProxy: handles integration with the registry All the other classes derive from WpGlobalProxy. The reason for separating WpGlobalProxy from WpProxy, though, is that classes such as WpImplNode / WpSpaDevice can also derive from WpProxy now, without interfacing with the registry. All objects that come with an "info" structure and have properties and/or params also implement the WpPipewireObject interface. This provides the API to query properties and get/set params. Essentially, this is implemented by all classes except WpMetadata (pw_metadata does not have info) This interface is implemented on each object separately, using a private "mixin", which is a set of vfunc implementations and helper functions (and macros) to facilitate the implementation of this interface. A notable difference to the old WpProxy is that now features can be deactivated, so it is possible to enable something and later disable it again. This commit disables modules, tests, tools, etc, to avoid growing the patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
#include "private/pipewire-object-mixin.h"
proxy-link: add new API
2019-07-05 10:22:28 -04: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-link")
docs: fix C API documentation to work nicely with doxygen & sphinx
2021-05-21 18:40:43 +03:00
/*! \defgroup wplink WpLink */
docs: api: Replace hotdoc specific commands with Doxygen specific commands
2021-05-13 17:54:58 +03:00
/*!
docs: fix C API documentation to work nicely with doxygen & sphinx
2021-05-21 18:40:43 +03:00
* \struct WpLink
*
* The WpLink class allows accessing the properties and methods of a
* PipeWire link object (`struct pw_link`).
*
* A WpLink is constructed internally when a new link appears on the
* PipeWire registry and it is made available through the WpObjectManager API.
* Alternatively, a WpLink can also be constructed using
* wp_link_new_from_factory(), which creates a new link object
* on the remote PipeWire server by calling into a factory.
link: add link state accessors and change signal
2022-05-26 15:42:45 +03:00
*
* \gproperties
*
* \gproperty{state, WpLinkState, G_PARAM_READABLE, The current state of the link}
*
* \gsignals
*
* \par state-changed
* \parblock
* \code
* void
* state_changed_callback (WpLink * self,
* WpLinkState * old_state,
* WpLinkState * new_state,
* gpointer user_data)
* \endcode
*
* Emitted when the link changes state. This is only emitted when
* WP_PIPEWIRE_OBJECT_FEATURE_INFO is enabled.
*
* Parameters:
* - `old_state` - the old state
* - `new_state` - the new state
*
* Flags: G_SIGNAL_RUN_LAST
* \endparblock
docs: api: Replace hotdoc specific commands with Doxygen specific commands
2021-05-13 17:54:58 +03:00
*/
docs: fix C API documentation to work nicely with doxygen & sphinx
2021-05-21 18:40:43 +03:00
link: add link state accessors and change signal
2022-05-26 15:42:45 +03:00
enum {
PROP_STATE = WP_PW_OBJECT_MIXIN_PROP_CUSTOM_START,
};
enum {
SIGNAL_STATE_CHANGED,
N_SIGNALS,
};
static guint32 signals[N_SIGNALS] = {0};
lib: drop the proxy- prefix from client, device, link, port & node
2020-01-22 18:54:45 +02:00
struct _WpLink
proxy-link: add new API
2019-07-05 10:22:28 -04: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;
proxy-link: add new API
2019-07-05 10:22:28 -04:00
};
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
static void wp_link_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 (WpLink, wp_link, WP_TYPE_GLOBAL_PROXY,
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
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_link_pw_object_mixin_priv_interface_init))
proxy-link: add new API
2019-07-05 10:22:28 -04:00
proxy-*: improve proxy subclasses * add proxy sync method * add wrapers for enum/set/subscribe_params * move the info structure handling to the subclasses * expose info->props as WpProperties
2019-08-27 17:33:25 +03:00
static void
lib: drop the proxy- prefix from client, device, link, port & node
2020-01-22 18:54:45 +02:00
wp_link_init (WpLink * self)
proxy-*: improve proxy subclasses * add proxy sync method * add wrapers for enum/set/subscribe_params * move the info structure handling to the subclasses * expose info->props as WpProperties
2019-08-27 17:33:25 +03:00
{
}
link: add link state accessors and change signal
2022-05-26 15:42:45 +03:00
static void
wp_link_get_property (GObject * object, guint property_id,
GValue * value, GParamSpec * pspec)
{
WpPwObjectMixinData *d = wp_pw_object_mixin_get_data (object);
switch (property_id) {
case PROP_STATE:
g_value_set_enum (value, d->info ?
((struct pw_link_info *) d->info)->state : 0);
break;
default:
wp_pw_object_mixin_get_property (object, property_id, value, pspec);
break;
}
}
link: add WP_LINK_FEATURE_ESTABLISHED to track when a link is PAUSED/ACTIVE This allows to transparently wait until a link is PAUSED before returning from the activation transition. This way we can also catch negotiation/allocation errors while activating a link. PAUSED is used instead of ACTIVE because ACTIVE depends on the nodes being activated as well. There are cases where a link may not activate the nodes (ex, a passive link) and the link may remain PAUSED for a long time. Related to: #294
2022-07-02 17:10:22 +03:00
static WpObjectFeatures
wp_link_get_supported_features (WpObject * object)
{
return wp_pw_object_mixin_get_supported_features (object)
| WP_LINK_FEATURE_ESTABLISHED;
}
enum {
STEP_WAIT_ESTABLISHED = WP_PW_OBJECT_MIXIN_STEP_CUSTOM_START,
};
lib: refactor WpProxy This is an attempt to unclutter the API of WpProxy and split functionality into smaller pieces, making it easier to work with. In this new class layout, we have the following classes: - WpObject: base class for everything; handles activating | and deactivating "features" |- WpProxy: base class for anything that wraps a pw_proxy; | handles events from pw_proxy and nothing more |- WpGlobalProxy: handles integration with the registry All the other classes derive from WpGlobalProxy. The reason for separating WpGlobalProxy from WpProxy, though, is that classes such as WpImplNode / WpSpaDevice can also derive from WpProxy now, without interfacing with the registry. All objects that come with an "info" structure and have properties and/or params also implement the WpPipewireObject interface. This provides the API to query properties and get/set params. Essentially, this is implemented by all classes except WpMetadata (pw_metadata does not have info) This interface is implemented on each object separately, using a private "mixin", which is a set of vfunc implementations and helper functions (and macros) to facilitate the implementation of this interface. A notable difference to the old WpProxy is that now features can be deactivated, so it is possible to enable something and later disable it again. This commit disables modules, tests, tools, etc, to avoid growing the patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
static void
wp_link_activate_execute_step (WpObject * object,
WpFeatureActivationTransition * transition, guint step,
WpObjectFeatures missing)
proxy: unify common info/params API in the WpProxy base class
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) {
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
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_link_parent_class)->
activate_execute_step (object, transition, step, missing);
break;
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
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;
link: add WP_LINK_FEATURE_ESTABLISHED to track when a link is PAUSED/ACTIVE This allows to transparently wait until a link is PAUSED before returning from the activation transition. This way we can also catch negotiation/allocation errors while activating a link. PAUSED is used instead of ACTIVE because ACTIVE depends on the nodes being activated as well. There are cases where a link may not activate the nodes (ex, a passive link) and the link may remain PAUSED for a long time. Related to: #294
2022-07-02 17:10:22 +03:00
case STEP_WAIT_ESTABLISHED:
/* just wait again, the state will be changed automatically */
break;
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
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
}
proxy-*: improve proxy subclasses * add proxy sync method * add wrapers for enum/set/subscribe_params * move the info structure handling to the subclasses * expose info->props as WpProperties
2019-08-27 17:33:25 +03:00
}
update to the latest pipewire API
2020-01-09 12:39:45 -05:00
static const struct pw_link_events link_events = {
PW_VERSION_LINK_EVENTS,
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
.info = (HandleEventInfoFunc(link)) wp_pw_object_mixin_handle_event_info,
proxy-link: add new API
2019-07-05 10:22:28 -04:00
};
static void
lib: drop the proxy- prefix from client, device, link, port & node
2020-01-22 18:54:45 +02:00
wp_link_pw_proxy_created (WpProxy * proxy, struct pw_proxy * pw_proxy)
proxy-link: add new API
2019-07-05 10:22:28 -04:00
{
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
wp_pw_object_mixin_handle_pw_proxy_created (proxy, pw_proxy,
link, &link_events);
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
}
global-proxy: destroy the global when proxy is destroyed
2021-05-12 13:52:02 -04:00
static void
wp_link_pw_proxy_destroyed (WpProxy * proxy)
{
wp_pw_object_mixin_handle_pw_proxy_destroyed (proxy);
link: add WP_LINK_FEATURE_ESTABLISHED to track when a link is PAUSED/ACTIVE This allows to transparently wait until a link is PAUSED before returning from the activation transition. This way we can also catch negotiation/allocation errors while activating a link. PAUSED is used instead of ACTIVE because ACTIVE depends on the nodes being activated as well. There are cases where a link may not activate the nodes (ex, a passive link) and the link may remain PAUSED for a long time. Related to: #294
2022-07-02 17:10:22 +03:00
wp_object_update_features (WP_OBJECT (proxy), 0, WP_LINK_FEATURE_ESTABLISHED);
global-proxy: destroy the global when proxy is destroyed
2021-05-12 13:52:02 -04:00
WP_PROXY_CLASS (wp_link_parent_class)->pw_proxy_destroyed (proxy);
}
proxy-link: add new API
2019-07-05 10:22:28 -04:00
static void
lib: drop the proxy- prefix from client, device, link, port & node
2020-01-22 18:54:45 +02:00
wp_link_class_init (WpLinkClass * klass)
proxy-link: add new API
2019-07-05 10:22:28 -04:00
{
proxy-*: improve proxy subclasses * add proxy sync method * add wrapers for enum/set/subscribe_params * move the info structure handling to the subclasses * expose info->props as WpProperties
2019-08-27 17:33:25 +03:00
GObjectClass *object_class = (GObjectClass *) klass;
lib: refactor WpProxy This is an attempt to unclutter the API of WpProxy and split functionality into smaller pieces, making it easier to work with. In this new class layout, we have the following classes: - WpObject: base class for everything; handles activating | and deactivating "features" |- WpProxy: base class for anything that wraps a pw_proxy; | handles events from pw_proxy and nothing more |- WpGlobalProxy: handles integration with the registry All the other classes derive from WpGlobalProxy. The reason for separating WpGlobalProxy from WpProxy, though, is that classes such as WpImplNode / WpSpaDevice can also derive from WpProxy now, without interfacing with the registry. All objects that come with an "info" structure and have properties and/or params also implement the WpPipewireObject interface. This provides the API to query properties and get/set params. Essentially, this is implemented by all classes except WpMetadata (pw_metadata does not have info) This interface is implemented on each object separately, using a private "mixin", which is a set of vfunc implementations and helper functions (and macros) to facilitate the implementation of this interface. A notable difference to the old WpProxy is that now features can be deactivated, so it is possible to enable something and later disable it again. This commit disables modules, tests, tools, etc, to avoid growing the patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
WpObjectClass *wpobject_class = (WpObjectClass *) klass;
proxy: throw an error if the proxy is destroyed during async constructions
2019-07-11 12:06:04 -04:00
WpProxyClass *proxy_class = (WpProxyClass *) klass;
proxy-link: add new API
2019-07-05 10:22:28 -04:00
link: add link state accessors and change signal
2022-05-26 15:42:45 +03:00
object_class->get_property = wp_link_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
link: add WP_LINK_FEATURE_ESTABLISHED to track when a link is PAUSED/ACTIVE This allows to transparently wait until a link is PAUSED before returning from the activation transition. This way we can also catch negotiation/allocation errors while activating a link. PAUSED is used instead of ACTIVE because ACTIVE depends on the nodes being activated as well. There are cases where a link may not activate the nodes (ex, a passive link) and the link may remain PAUSED for a long time. Related to: #294
2022-07-02 17:10:22 +03:00
wpobject_class->get_supported_features = wp_link_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 =
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
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_link_activate_execute_step;
proxy-*: improve proxy subclasses * add proxy sync method * add wrapers for enum/set/subscribe_params * move the info structure handling to the subclasses * expose info->props as WpProperties
2019-08-27 17:33:25 +03:00
proxy/core: refactor object creation * core no longer exposes create_remote/local_object * node, device & link have constructor methods to enable the create_remote_object functionality * added WpImplNode to wrap pw_impl_node and allow creating "local" node instances * added WpSpaDevice to wrap spa_device and allow creating "local" device instances * exporting objects in all cases now happens by requesting FEATURE_BOUND from the proxy, eliminating the need for WpExported * replaced WpMonitor by new, simpler code directly in module-monitor * the proxy type lookup table in WpProxy is gone, we now use a field on the class structure of every WpProxy subclass and iterate through all the class structures instead; this is more flexible and extensible
2020-01-30 17:41:25 +02:00
proxy_class->pw_iface_type = PW_TYPE_INTERFACE_Link;
proxy_class->pw_iface_version = PW_VERSION_LINK;
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_link_pw_proxy_created;
global-proxy: destroy the global when proxy is destroyed
2021-05-12 13:52:02 -04:00
proxy_class->pw_proxy_destroyed = wp_link_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
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
wp_pw_object_mixin_class_override_properties (object_class);
link: add link state accessors and change signal
2022-05-26 15:42:45 +03:00
g_object_class_install_property (object_class, PROP_STATE,
g_param_spec_enum ("state", "state", "state", WP_TYPE_LINK_STATE, 0,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS));
signals[SIGNAL_STATE_CHANGED] = g_signal_new (
"state-changed", G_TYPE_FROM_CLASS (klass),
G_SIGNAL_RUN_LAST, 0, NULL, NULL, NULL, G_TYPE_NONE, 2,
WP_TYPE_LINK_STATE, WP_TYPE_LINK_STATE);
}
static void
wp_link_process_info (gpointer instance, gpointer old_info, gpointer i)
{
link: add WP_LINK_FEATURE_ESTABLISHED to track when a link is PAUSED/ACTIVE This allows to transparently wait until a link is PAUSED before returning from the activation transition. This way we can also catch negotiation/allocation errors while activating a link. PAUSED is used instead of ACTIVE because ACTIVE depends on the nodes being activated as well. There are cases where a link may not activate the nodes (ex, a passive link) and the link may remain PAUSED for a long time. Related to: #294
2022-07-02 17:10:22 +03:00
WpObject *object = instance;
link: add link state accessors and change signal
2022-05-26 15:42:45 +03:00
const struct pw_link_info *info = i;
if (info->change_mask & PW_LINK_CHANGE_MASK_STATE) {
enum pw_link_state old_state = old_info ?
((struct pw_link_info *) old_info)->state : PW_LINK_STATE_INIT;
link: add WP_LINK_FEATURE_ESTABLISHED to track when a link is PAUSED/ACTIVE This allows to transparently wait until a link is PAUSED before returning from the activation transition. This way we can also catch negotiation/allocation errors while activating a link. PAUSED is used instead of ACTIVE because ACTIVE depends on the nodes being activated as well. There are cases where a link may not activate the nodes (ex, a passive link) and the link may remain PAUSED for a long time. Related to: #294
2022-07-02 17:10:22 +03:00
link: add link state accessors and change signal
2022-05-26 15:42:45 +03:00
g_signal_emit (instance, signals[SIGNAL_STATE_CHANGED], 0,
old_state, info->state);
link: add WP_LINK_FEATURE_ESTABLISHED to track when a link is PAUSED/ACTIVE This allows to transparently wait until a link is PAUSED before returning from the activation transition. This way we can also catch negotiation/allocation errors while activating a link. PAUSED is used instead of ACTIVE because ACTIVE depends on the nodes being activated as well. There are cases where a link may not activate the nodes (ex, a passive link) and the link may remain PAUSED for a long time. Related to: #294
2022-07-02 17:10:22 +03:00
if (info->state >= PW_LINK_STATE_PAUSED && old_state < PW_LINK_STATE_PAUSED)
wp_object_update_features (object, WP_LINK_FEATURE_ESTABLISHED, 0);
else if (info->state < PW_LINK_STATE_PAUSED && old_state >= PW_LINK_STATE_PAUSED)
wp_object_update_features (object, 0, WP_LINK_FEATURE_ESTABLISHED);
link: add link state accessors and change signal
2022-05-26 15:42:45 +03:00
}
lib: refactor WpProxy This is an attempt to unclutter the API of WpProxy and split functionality into smaller pieces, making it easier to work with. In this new class layout, we have the following classes: - WpObject: base class for everything; handles activating | and deactivating "features" |- WpProxy: base class for anything that wraps a pw_proxy; | handles events from pw_proxy and nothing more |- WpGlobalProxy: handles integration with the registry All the other classes derive from WpGlobalProxy. The reason for separating WpGlobalProxy from WpProxy, though, is that classes such as WpImplNode / WpSpaDevice can also derive from WpProxy now, without interfacing with the registry. All objects that come with an "info" structure and have properties and/or params also implement the WpPipewireObject interface. This provides the API to query properties and get/set params. Essentially, this is implemented by all classes except WpMetadata (pw_metadata does not have info) This interface is implemented on each object separately, using a private "mixin", which is a set of vfunc implementations and helper functions (and macros) to facilitate the implementation of this interface. A notable difference to the old WpProxy is that now features can be deactivated, so it is possible to enable something and later disable it again. This commit disables modules, tests, tools, etc, to avoid growing the patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
}
static void
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
wp_link_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
{
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
wp_pw_object_mixin_priv_interface_info_init_no_params (iface, link, LINK);
link: add link state accessors and change signal
2022-05-26 15:42:45 +03:00
iface->process_info = wp_link_process_info;
proxy-link: add new API
2019-07-05 10:22:28 -04:00
}
proxy/core: refactor object creation * core no longer exposes create_remote/local_object * node, device & link have constructor methods to enable the create_remote_object functionality * added WpImplNode to wrap pw_impl_node and allow creating "local" node instances * added WpSpaDevice to wrap spa_device and allow creating "local" device instances * exporting objects in all cases now happens by requesting FEATURE_BOUND from the proxy, eliminating the need for WpExported * replaced WpMonitor by new, simpler code directly in module-monitor * the proxy type lookup table in WpProxy is gone, we now use a field on the class structure of every WpProxy subclass and iterate through all the class structures instead; this is more flexible and extensible
2020-01-30 17:41:25 +02:00
docs: api: Replace hotdoc specific commands with Doxygen specific commands
2021-05-13 17:54:58 +03:00
/*!
docs: fix C API documentation to work nicely with doxygen & sphinx
2021-05-21 18:40:43 +03:00
* \brief Constructs a link on the PipeWire server by asking the remote factory
* \a factory_name to create it.
proxy/core: refactor object creation * core no longer exposes create_remote/local_object * node, device & link have constructor methods to enable the create_remote_object functionality * added WpImplNode to wrap pw_impl_node and allow creating "local" node instances * added WpSpaDevice to wrap spa_device and allow creating "local" device instances * exporting objects in all cases now happens by requesting FEATURE_BOUND from the proxy, eliminating the need for WpExported * replaced WpMonitor by new, simpler code directly in module-monitor * the proxy type lookup table in WpProxy is gone, we now use a field on the class structure of every WpProxy subclass and iterate through all the class structures instead; this is more flexible and extensible
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
docs: fix C API documentation to work nicely with doxygen & sphinx
2021-05-21 18:40:43 +03:00
* WP_PROXY_FEATURE_BOUND. When this feature is ready, the link 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 link cannot be created, this activation operation
proxy/core: refactor object creation * core no longer exposes create_remote/local_object * node, device & link have constructor methods to enable the create_remote_object functionality * added WpImplNode to wrap pw_impl_node and allow creating "local" node instances * added WpSpaDevice to wrap spa_device and allow creating "local" device instances * exporting objects in all cases now happens by requesting FEATURE_BOUND from the proxy, eliminating the need for WpExported * replaced WpMonitor by new, simpler code directly in module-monitor * the proxy type lookup table in WpProxy is gone, we now use a field on the class structure of every WpProxy subclass and iterate through all the class structures instead; this is more flexible and extensible
2020-01-30 17:41:25 +02:00
* will fail.
*
docs: fix C API documentation to work nicely with doxygen & sphinx
2021-05-21 18:40:43 +03:00
* \ingroup wplink
* \param core the wireplumber core
* \param factory_name the pipewire factory name to construct the link
* \param properties (nullable) (transfer full): the properties to pass to the
* factory
* \returns (nullable) (transfer full): the new link or NULL if the core
proxy/core: refactor object creation * core no longer exposes create_remote/local_object * node, device & link have constructor methods to enable the create_remote_object functionality * added WpImplNode to wrap pw_impl_node and allow creating "local" node instances * added WpSpaDevice to wrap spa_device and allow creating "local" device instances * exporting objects in all cases now happens by requesting FEATURE_BOUND from the proxy, eliminating the need for WpExported * replaced WpMonitor by new, simpler code directly in module-monitor * the proxy type lookup table in WpProxy is gone, we now use a field on the class structure of every WpProxy subclass and iterate through all the class structures instead; this is more flexible and extensible
2020-01-30 17:41:25 +02:00
* is not connected and therefore the link cannot be created
*/
WpLink *
wp_link_new_from_factory (WpCore * core,
const gchar * factory_name, WpProperties * properties)
{
g_autoptr (WpProperties) props = properties;
global-proxy: delay object creation until bound feature is requested Allows handling errors if creation fails
2021-05-17 11:08:04 -04:00
return g_object_new (WP_TYPE_LINK,
"core", core,
"factory-name", factory_name,
"global-properties", props,
NULL);
proxy/core: refactor object creation * core no longer exposes create_remote/local_object * node, device & link have constructor methods to enable the create_remote_object functionality * added WpImplNode to wrap pw_impl_node and allow creating "local" node instances * added WpSpaDevice to wrap spa_device and allow creating "local" device instances * exporting objects in all cases now happens by requesting FEATURE_BOUND from the proxy, eliminating the need for WpExported * replaced WpMonitor by new, simpler code directly in module-monitor * the proxy type lookup table in WpProxy is gone, we now use a field on the class structure of every WpProxy subclass and iterate through all the class structures instead; this is more flexible and extensible
2020-01-30 17:41:25 +02:00
}
link: add method to get object ids
2020-05-05 16:29:17 +03:00
docs: api: Replace hotdoc specific commands with Doxygen specific commands
2021-05-13 17:54:58 +03:00
/*!
docs: fix C API documentation to work nicely with doxygen & sphinx
2021-05-21 18:40:43 +03:00
* \brief Retrieves the ids of the objects that are linked by this link
link: add method to get object ids
2020-05-05 16:29:17 +03:00
*
docs: fix C API documentation to work nicely with doxygen & sphinx
2021-05-21 18:40:43 +03:00
* \remark Requires WP_PIPEWIRE_OBJECT_FEATURE_INFO
link: add method to get object ids
2020-05-05 16:29:17 +03:00
*
docs: fix C API documentation to work nicely with doxygen & sphinx
2021-05-21 18:40:43 +03:00
* \ingroup wplink
* \param self the link
* \param output_node (out) (optional): the bound id of the output (source) node
* \param output_port (out) (optional): the bound id of the output (source) port
* \param input_node (out) (optional): the bound id of the input (sink) node
* \param input_port (out) (optional): the bound id of the input (sink) port
link: add method to get object ids
2020-05-05 16:29:17 +03:00
*/
void
wp_link_get_linked_object_ids (WpLink * self,
guint32 * output_node, guint32 * output_port,
guint32 * input_node, guint32 * input_port)
{
g_return_if_fail (WP_IS_LINK (self));
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
WpPwObjectMixinData *d = wp_pw_object_mixin_get_data (self);
struct pw_link_info *info = d->info;
g_return_if_fail (info);
link: add method to get object ids
2020-05-05 16:29:17 +03:00
if (output_node)
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
*output_node = info->output_node_id;
link: add method to get object ids
2020-05-05 16:29:17 +03:00
if (output_port)
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
*output_port = info->output_port_id;
link: add method to get object ids
2020-05-05 16:29:17 +03:00
if (input_node)
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
*input_node = info->input_node_id;
link: add method to get object ids
2020-05-05 16:29:17 +03:00
if (input_port)
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
*input_port = info->input_port_id;
docs: fix C API documentation to work nicely with doxygen & sphinx
2021-05-21 18:40:43 +03:00
}
link: add link state accessors and change signal
2022-05-26 15:42:45 +03:00
/*!
* \brief Gets the current state of the link
* \ingroup wplink
* \param self the link
* \param error (out) (optional) (transfer none): the error
* \returns the current state of the link
* \since 0.4.11
*/
WpLinkState
wp_link_get_state (WpLink * self, const gchar ** error)
{
g_return_val_if_fail (WP_IS_LINK (self), WP_LINK_STATE_ERROR);
g_return_val_if_fail (wp_object_get_active_features (WP_OBJECT (self)) &
WP_PIPEWIRE_OBJECT_FEATURE_INFO, WP_LINK_STATE_ERROR);
WpPwObjectMixinData *d = wp_pw_object_mixin_get_data (self);
const struct pw_link_info *info = d->info;
if (error)
*error = info->error;
return (WpLinkState) info->state;
}
Reference in a new issue Copy permalink