Changes:
- Configuration files are no longer located by libpipewire,
which allows us to control the paths that are being looked up.
This is a requirement for installations where pipewire and
wireplumber are built using different prefixes, in which case
the configuration files of wireplumber end up being installed in
a place that libpipewire doesn't look into...
- The location of conf files is now again $prefix/share/wireplumber,
/etc/wireplumber and $XDG_CONFIG_HOME/wireplumber, instead of using
the pipewire directories. Also, since the previous commits, we now
also support $XDG_CONFIG_DIRS/wireplumber (typically /etc/xdg/wireplumber)
and $XDG_DATA_DIRS/wireplumber for system-wide configuration.
- Since libpipewire doesn't expose the parser, we now also do the
parsing of sections ourselves. This has the advantage that we can
optimize it a bit for our use case.
- The WpConf API has changed to not be a singleton and it is a
property of WpCore instead. The configuration is now expected
to be opened before the core is created, which allows the caller
to identify configuration errors in advance. By not being a singleton,
we can also reuse the WpConf API to open other SPA-JSON files.
- WpConf also now has a lazy loading mechanism. The configuration
files are mmap'ed and the various sections are located in advance,
but not parsed until they are actually requested. Also, the sections
are not copied in memory, unlike what happens in libpipewire. They
are only copied when merging is needed.
- WpCore now disables loading of a configuration file in pw_context,
if a WpConf is provided. This is to have complete control here.
The 'context.spa-libs' and 'context.modules' sections are still
loaded, but we load them in WpConf and pass them down to pw_context
for parsing. If a WpConf is not provided, pw_context is left to load
the default configuration file (client.conf normally).
Add command for changing log level for Pipewire or Wireplumber daemons
at runtime.
It can be done with pw-metadata, but make it easier so that the user
doesn't need to look up Wireplumber client ids.
The previous naming convention was confusing because it did not make
it explicit that the string is not being copied. We had this wrong already
in the Lua bindings and thanks to some miracle it hasn't backfired so far
(it was using the "wrap" behaviour with a string that doesn't stay alive).
In some places we actually need the "copy" behaviour and in some other
places we need the "wrap" behaviour, so let's have both variants available.
This is already done for `WpDaemon` and `WpExec`, so let's do it
here as well. This prevents some memory leaks in error paths,
which makes it easier to find real issues in the ASan output.
Each component can optionally "provide" a feature, which is basically
a string that describes the feature (ex. "support.dbus"). If the
component loads successfully, the feature is marked as provided and
can be tested for its presence with wp_core_test_feature()
There is no reason to return the component object... all components
are supposed to be long-lived objects that are referenced by the
registry and there is API to find them. The caller is only interested
in the success or failure of the operation.
Regarding the core parameter, the case used to be that WpComponentLoader
was a WpPlugin, so it had a reference to the core internally, but since
this is no longer a requirement, we need to pass this explicitly
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.
-Scripts loaded with wpexec will also need 'module-standard-event-source'
to be able to convert the pipewire signals to wireplumber events.
-Simplify the init transition states.
Unlike the rest of subcommands, The ID for the clear-default subcommand must be
a setting ID, not a pipewire Object ID. This means we cannot use the parse_id()
and translate_id() helper functions because the setting ID 0 is acceptable, and
the @DEFAULT_AUDIO_SINK@, @DEFAULT_AUDIO_SOURCE@ and @DEFAULT_VIDEO_SOURCE@
strings are not acceptable.
The 'set-volume' and 'set-mute' commands have a new --pid flag to allow changing
the volume or mute for all client nodes that are created by a specific process.
Previously, pw_init calls setlocale(), but this will change in future.
Setting the locale should be done by the main application, and is needed
in wireplumber for e.g. for translated UI elements.
Set the locale in main() for wireplumber daemon and tools, to have the
locale set also with the new pw_init behavior.
Set also LC_NUMERIC to C, to match old pw_init behavior.
This also improves the status output to display the configured default node
names using the new get-default-configured-node-name API, and refactors
set-default to also use the new set-default-configured-node-name API from
the default-nodes-api module.
pipewire's client.conf sets the default log level to 0, which is not
good for wpexec, as lua runtime errors are reported as warnings currently.
Also, let's use fprintf() for local cli errors to make sure they get printed
even if the log level is 0
We have ended up not using them, so let's not carry them
in the ABI of 0.4
We can always revert that, but let's first decide how
these objects should be used
This is mainly for security reasons. This way, we can limit the
permissions of wpexec without limiting wireplumber, for instance
with pipewire's default module-access, which limits apps based on
their executable name
