2019-08-27 18:26:07 +03:00
|
|
|
/* WirePlumber
|
|
|
|
|
*
|
|
|
|
|
* Copyright © 2019 Collabora Ltd.
|
|
|
|
|
* @author George Kiagiadakis <george.kiagiadakis@collabora.com>
|
|
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: MIT
|
|
|
|
|
*/
|
|
|
|
|
|
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 "client.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"
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
#include "private/pipewire-object-mixin.h"
|
2019-08-27 18:26:07 +03: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-client")
|
|
|
|
|
|
2021-05-21 18:40:43 +03:00
|
|
|
/*! \defgroup wpclient WpClient */
|
2021-05-13 17:54:58 +03:00
|
|
|
/*!
|
2021-05-21 18:40:43 +03:00
|
|
|
* \struct WpClient
|
2021-05-13 17:54:58 +03:00
|
|
|
*
|
2021-05-21 18:40:43 +03:00
|
|
|
* The WpClient class allows accessing the properties and methods of a PipeWire
|
|
|
|
|
* client object (`struct pw_client`). A WpClient is constructed internally
|
2021-05-13 17:54:58 +03:00
|
|
|
* when a new client connects to PipeWire and it is made available through the
|
2021-05-21 18:40:43 +03:00
|
|
|
* WpObjectManager API.
|
2021-05-13 17:54:58 +03:00
|
|
|
*/
|
|
|
|
|
|
2020-01-22 18:54:45 +02:00
|
|
|
struct _WpClient
|
2019-08-27 18:26:07 +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
|
|
|
WpGlobalProxy parent;
|
2019-08-27 18:26:07 +03:00
|
|
|
};
|
|
|
|
|
|
2020-11-25 14:02:33 +02:00
|
|
|
static void wp_client_pw_object_mixin_priv_interface_init (
|
|
|
|
|
WpPwObjectMixinPrivInterface * iface);
|
2019-08-27 18:26:07 +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 (WpClient, wp_client, 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_client_pw_object_mixin_priv_interface_init))
|
2019-08-27 18:26:07 +03:00
|
|
|
|
|
|
|
|
static void
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
wp_client_init (WpClient * self)
|
2019-08-27 18:26:07 +03:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
static void
|
|
|
|
|
wp_client_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_client_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;
|
|
|
|
|
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
|
|
|
}
|
2019-08-27 18:26:07 +03:00
|
|
|
}
|
|
|
|
|
|
2020-01-09 12:39:45 -05:00
|
|
|
static const struct pw_client_events client_events = {
|
|
|
|
|
PW_VERSION_CLIENT_EVENTS,
|
2020-11-25 14:02:33 +02:00
|
|
|
.info = (HandleEventInfoFunc(client)) wp_pw_object_mixin_handle_event_info,
|
2019-08-27 18:26:07 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static void
|
2020-01-22 18:54:45 +02:00
|
|
|
wp_client_pw_proxy_created (WpProxy * proxy, struct pw_proxy * pw_proxy)
|
2019-08-27 18:26:07 +03:00
|
|
|
{
|
2020-11-25 14:02:33 +02:00
|
|
|
wp_pw_object_mixin_handle_pw_proxy_created (proxy, pw_proxy,
|
|
|
|
|
client, &client_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
|
|
|
}
|
|
|
|
|
|
2021-05-12 13:52:02 -04:00
|
|
|
static void
|
|
|
|
|
wp_client_pw_proxy_destroyed (WpProxy * proxy)
|
|
|
|
|
{
|
|
|
|
|
wp_pw_object_mixin_handle_pw_proxy_destroyed (proxy);
|
|
|
|
|
|
|
|
|
|
WP_PROXY_CLASS (wp_client_parent_class)->pw_proxy_destroyed (proxy);
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-27 18:26:07 +03:00
|
|
|
static void
|
2020-01-22 18:54:45 +02:00
|
|
|
wp_client_class_init (WpClientClass * klass)
|
2019-08-27 18:26:07 +03:00
|
|
|
{
|
|
|
|
|
GObjectClass *object_class = (GObjectClass *) klass;
|
lib: refactor WpProxy
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
|
|
|
WpObjectClass *wpobject_class = (WpObjectClass *) klass;
|
2019-08-27 18:26:07 +03: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_client_activate_execute_step;
|
2019-08-27 18:26:07 +03:00
|
|
|
|
2020-01-30 17:41:25 +02:00
|
|
|
proxy_class->pw_iface_type = PW_TYPE_INTERFACE_Client;
|
|
|
|
|
proxy_class->pw_iface_version = PW_VERSION_CLIENT;
|
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_client_pw_proxy_created;
|
2021-05-12 13:52:02 -04:00
|
|
|
proxy_class->pw_proxy_destroyed = wp_client_pw_proxy_destroyed;
|
2019-08-27 18:26:07 +03: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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2020-11-25 14:02:33 +02:00
|
|
|
wp_client_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_no_params (iface, client, CLIENT);
|
2019-08-27 18:26:07 +03:00
|
|
|
}
|
|
|
|
|
|
2021-10-13 11:09:11 +03:00
|
|
|
/*!
|
|
|
|
|
* \brief Send an error to the client
|
|
|
|
|
*
|
|
|
|
|
* \ingroup wpclient
|
|
|
|
|
* \param self the client
|
|
|
|
|
* \param id the global id to report the error on
|
|
|
|
|
* \param res an errno style error code
|
|
|
|
|
* \param message the error message string
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
wp_client_send_error (WpClient * self, guint32 id, int res,
|
|
|
|
|
const gchar * message)
|
|
|
|
|
{
|
|
|
|
|
struct pw_client *pwp;
|
|
|
|
|
|
|
|
|
|
g_return_if_fail (WP_IS_CLIENT (self));
|
|
|
|
|
|
|
|
|
|
pwp = (struct pw_client *) wp_proxy_get_pw_proxy (WP_PROXY (self));
|
|
|
|
|
g_return_if_fail (pwp != NULL);
|
|
|
|
|
|
|
|
|
|
pw_client_error (pwp, id, res, message);
|
|
|
|
|
}
|
|
|
|
|
|
2021-05-13 17:54:58 +03:00
|
|
|
/*!
|
2021-05-21 18:40:43 +03:00
|
|
|
* \brief Update client's permissions on a list of objects.
|
2021-05-13 17:54:58 +03:00
|
|
|
*
|
2021-05-21 18:40:43 +03:00
|
|
|
* An object id of `-1` can be used to set the default object permissions
|
|
|
|
|
* for this client
|
2020-02-17 15:39:19 +02:00
|
|
|
*
|
2021-05-21 18:40:43 +03:00
|
|
|
* \ingroup wpclient
|
|
|
|
|
* \param self the client
|
|
|
|
|
* \param n_perm the number of permissions specified in the variable arguments
|
|
|
|
|
* \param ... \a n_perm pairs of guint32 numbers; the first number is the
|
|
|
|
|
* object id and the second is the permissions that this client should have
|
|
|
|
|
* on this object
|
2020-02-17 15:39:19 +02:00
|
|
|
*/
|
2019-08-27 18:26:07 +03:00
|
|
|
void
|
2020-01-22 18:54:45 +02:00
|
|
|
wp_client_update_permissions (WpClient * self, guint n_perm, ...)
|
2019-08-27 18:26:07 +03:00
|
|
|
{
|
|
|
|
|
va_list args;
|
|
|
|
|
struct pw_permission *perm =
|
|
|
|
|
g_alloca (n_perm * sizeof (struct pw_permission));
|
|
|
|
|
|
|
|
|
|
va_start (args, n_perm);
|
2020-12-20 22:14:00 +02:00
|
|
|
for (guint i = 0; i < n_perm; i++) {
|
2019-08-27 18:26:07 +03:00
|
|
|
perm[i].id = va_arg (args, guint32);
|
|
|
|
|
perm[i].permissions = va_arg (args, guint32);
|
|
|
|
|
}
|
|
|
|
|
va_end (args);
|
|
|
|
|
|
2020-01-22 18:54:45 +02:00
|
|
|
wp_client_update_permissions_array (self, n_perm, perm);
|
2019-08-27 18:26:07 +03:00
|
|
|
}
|
|
|
|
|
|
2021-05-13 17:54:58 +03:00
|
|
|
/*!
|
2021-05-21 18:40:43 +03:00
|
|
|
* \brief Update client's permissions on a list of objects.
|
2021-05-13 17:54:58 +03:00
|
|
|
*
|
2021-05-21 18:40:43 +03:00
|
|
|
* An object id of `-1` can be used to set the default object permissions
|
|
|
|
|
* for this client
|
2021-05-13 17:54:58 +03:00
|
|
|
*
|
2021-05-21 18:40:43 +03:00
|
|
|
* \ingroup wpclient
|
|
|
|
|
* \param self the client
|
|
|
|
|
* \param n_perm the number of permissions specified in the \a permissions array
|
|
|
|
|
* \param permissions (array length=n_perm) (element-type pw_permission): an array
|
|
|
|
|
* of permissions per object id
|
2020-02-17 15:39:19 +02:00
|
|
|
*/
|
2019-08-27 18:26:07 +03:00
|
|
|
void
|
2020-01-22 18:54:45 +02:00
|
|
|
wp_client_update_permissions_array (WpClient * self,
|
2019-08-27 18:26:07 +03:00
|
|
|
guint n_perm, const struct pw_permission *permissions)
|
|
|
|
|
{
|
2020-01-09 12:39:45 -05:00
|
|
|
struct pw_client *pwp;
|
2019-08-27 18:26:07 +03:00
|
|
|
int client_update_permissions_result;
|
|
|
|
|
|
2020-01-22 18:54:45 +02:00
|
|
|
g_return_if_fail (WP_IS_CLIENT (self));
|
2019-08-27 18:26:07 +03:00
|
|
|
|
2020-01-09 12:39:45 -05:00
|
|
|
pwp = (struct pw_client *) wp_proxy_get_pw_proxy (WP_PROXY (self));
|
2019-08-27 18:26:07 +03:00
|
|
|
g_return_if_fail (pwp != NULL);
|
|
|
|
|
|
2020-01-09 12:39:45 -05:00
|
|
|
client_update_permissions_result = pw_client_update_permissions (
|
2019-08-27 18:26:07 +03:00
|
|
|
pwp, n_perm, permissions);
|
|
|
|
|
g_warn_if_fail (client_update_permissions_result >= 0);
|
2021-05-21 18:40:43 +03:00
|
|
|
}
|
2023-10-14 19:50:54 +03:00
|
|
|
|
|
|
|
|
/*!
|
|
|
|
|
* \brief Updates the properties of \a self
|
|
|
|
|
*
|
|
|
|
|
* This requires W and X permissions on the client.
|
|
|
|
|
*
|
|
|
|
|
* \ingroup wpclient
|
|
|
|
|
* \param self the client
|
|
|
|
|
* \param updates (transfer full): updates to apply to the properties of
|
|
|
|
|
* \a self; this does not need to include properties that have not changed
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
wp_client_update_properties (WpClient * self, WpProperties * updates)
|
|
|
|
|
{
|
|
|
|
|
g_autoptr (WpProperties) upd = updates;
|
|
|
|
|
struct pw_client *pwp;
|
|
|
|
|
int client_update_properties_result;
|
|
|
|
|
|
|
|
|
|
g_return_if_fail (WP_IS_CLIENT (self));
|
|
|
|
|
g_return_if_fail (updates != NULL);
|
|
|
|
|
|
|
|
|
|
pwp = (struct pw_client *) wp_proxy_get_pw_proxy (WP_PROXY (self));
|
|
|
|
|
g_return_if_fail (pwp != NULL);
|
|
|
|
|
|
|
|
|
|
client_update_properties_result = pw_client_update_properties (
|
|
|
|
|
pwp, wp_properties_peek_dict (upd));
|
|
|
|
|
|
|
|
|
|
g_warn_if_fail (client_update_properties_result >= 0);
|
|
|
|
|
}
|