Move nested objects/arrays from wireplumber.settings into their own section.
Currently, nested objects or arrays in the wireplumber.settings
section from the configuration cannot be merged if they are defined multiple times in different files. This is because the PipeWire configuration only allows to overwrite top level objects (sections), meaning that nested arrays and objects are completely overridden when merging sections.
I don't think defining everything in a wireplumber.settings
section is a good idea for the wireplumber configuration, because users would be forced to edit the existing wireplumber configuration if they just want to add a new ALSA rule for example (or setting a ALSA/Bluez/V4L2 monitor property), instead of just dropping a new configuration file with the ALSA rule they want to add.
The idea of this MR is to move all nested objects/arrays from wireplumber.settings
that cannot be changed at runtime (such as the rules and monitor properties) to their own section. For example, the monitor.alsa.rules
nested array from wireplumber.settings
is moved into its own wireplumber.alsa.rules
top level section, the monitor.alsa.properties
nested object from wireplumber.settings
is moved into its own wireplumber.alsa.properties
top level section, etc...
In order to do the above, a new WpConf
API was added to allow users get any configuration value from any section easily. Note that the WpConf
API is not a replacement for the current WpSettings
API, the WpSettings
is still needed as it allows subscribing callbacks when a settings has changed in the metadata at runtime.
It is important to differentiate WpConf
from WpSettings
. Here are the differences:
- WpConf:
- It is not associated with any WpMetadata object.
- It contains values that cannot be changed at runtime (Eg: rules, module dependencies and monitor properties).
- It provides an API to easily access any value in any section of the
wireplumber.conf
file (even the PipeWirecontext.*
sections). The same sections and arrays are merged if they are defined in multiple files. - It provides an API to easily apply rules to matching properties.
- WpSettings:
- It is associated with a WpMetadata object (
sm-settings
). - It only contains values that can be changed at runtime (Eg: the
move
andfollow
settings from policy-node.lua) - It provides an API to easily subscribe callbacks when a value has changed in the metadata at runtime.
- It does not have an API to apply rules to matching properties (this has been moved to WpConf as rules cannot be changed at runtime)
- The
module-settings
is charged to select what values from the configuration are considered settings (this is thewireplumber.settings
section from the configuration). This module also is charged to save and load persistent settings.
- It is associated with a WpMetadata object (
I recommend having a look at the wireplumber configuration of this MR to understand better the changes.
cc @ashoks