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.
This change completely refactors the way components are loaded in wireplumber:
- The module_init() function must return a GObject now. This object is either
a WpPlugin or a WpSiFactory in the current modules.
- When the component loader initializes a module, it automatically registers
the WpPlugin or WpSiFactory with their respective methods. There is no need
to register the WpPlugin or WpSiFactory in the module now.
- The wp_core_load_component() API has been refactored to be asynchronows. This
allows the component loader to automatically activate WpPlugin objects, and
therefore allows the application to directly get the WpPlugin without having
to find it. This simplifies a lot of things.
- The 'ifexists' and 'nofail' component flags now work even if the respective
WpPlugin could not be activated.
- The code that loads components in main.c has also been simplified a lot,
and the option to load dangling components has also been removed.
The move to the WpDbus API dropped the "state" property from the plugin,
but left the property enum and use of it in alsa.lua. Remove the enum and
port over the code in alsa.lua.
We're using the WpReserveDevice's name as key in the hash table, so we
must update the key as well when we replace an item in the hashtable -
the old device (and its name) will be released.
The side-effect of this is that the *third* device with an identical
name will no longer replace the previous device. This results in the
following sequence:
- dev1 added: name Audio0
- dev1 requests name owner Audio0
- dev2 added: name Audio0
- replace dev1 in the hashtable
- dev1 emits "release" signal
- dev1 unowns the Audio0 name
- dev2 requests name owner Audio0
- dev3 added: name Audio0
- adds to the hashtable because the existing key is now undefined
- dev3 requests name owner Audio0
- error, you cannot request ownership for the same name twice
Fixes#93
This change also keeps the plugin always activated, regardless of whether the
DBus connection is closed or not, which is useful when the dbus service is
restarted.
The component loader is a more generic and extensible mechanism
of loading components; modules are one type of component...
The idea is to make scripts and config files also be components,
loaded by plugins that inherit WpComponentLoader
* use the activate/deactivate system from WpObject,
which allows async activation and error reporting
* drop 'module' property, use 'core' from WpObject
This one offers API to interract on a lower level with
the D-Bus reservation API and uses GDBus high level bindings only.
Also, this one implements the full Acquire procedure, calling
RequestRelease() on the peer and requesting the name again with
REPLACE_EXISTING
