At the moment, the same transition can be completed multiple times
(assuming sufficiently high reference count):
return_error()
finish()
return_error()
The consequence of that is that the transition closure will be
invoked multiple times. This is unexpected.
Add some guards against completing a transition or calling finish()
multiple times.
Fixes#628
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.
- WpSettings is a singleton object which attaches itself to the core
and registry, it provides a get_instance () for its clients.
- WpSettings provides API to get/set wireplumber settings and rules.
- main.c loads the new object and makes sure it is available for
for all the modules and scripts. This is achieved by introducing
a new activation step.
- Add the lua bindings for get_setting API.
wp_transition_get_completed incorrectly returns TRUE for transitions
that have not been advanced at least once, and hence are obviously not
completed. This is because transitions start at STEP_NONE, and
completed transition is also indicated by STEP_NONE.
Fix this by adding a private flag to track whether transition was
started.
Fixes object managers sometimes missing object-changed events. How that
happens is the following:
- object activation transitions are advanced in idle callback
- they are aborted on registry global removal events
- registry global removal event can arrive before the idle callback
- wp_object_abort_activation uses wp_transition_get_completed to
determine whether transition was completed, but it returned bogus
values on transitions that hadn't been started.
Also rename the intermediate lua api table WpDebug -> WpLog
Keeps things more consistent with the function names (wp_log*),
with the lua api (Log.*) and with pipewire using log.{h,c} as well.
After all, these functions are for logging...
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.
This is an asynchronous operation class, like GTask,
but it is made to execute several operations underneath,
using a state machine, instead of just a single operation.