This makes things more consistent and allows us also to add more
search paths in the future if necessary.
Also, stop using g_module_build_path() because it's deprecated and
build the path manually. This obviously is not portable to Windows/Mac
or other exotic platforms, but portability is not important at this
point. PipeWire is also not portable beyond Linux & BSD.
This adds support for the system-wide locations for configuration and
data files, as defined by the XDG Base Directory Specification.
In addition, it adds two flag groups, CONFIGURATION and DATA, to the
base-dirs system, so that we don't have to hard-code the combinations
of flags everywhere.
Instead, make it so that WIREPLUMBER_*_DIR environment variables can
contain a list of directories to look into. This is safer and,
as a bonus, allows for more control over the lookup directories.
Using the G_TEST_SRCDIR variable can cause problems for tests of other
projects that use libwireplumber and may also lead to unexpected
behavior by not being obvious that this causes wireplumber to skip
looking in its standard directories...
This also brings back WIREPLUMBER_CONFIG_DIR, which is going to be
needed again for the upcoming WpConf changes.
Previously files would be sorted across all configuration dirs
so their filename was all that mattered, not the priority of the directory.
Ex. you could get:
- /etc/wireplumber/10-foo.conf
- /usr/share/wireplumber/20-bar.conf
- $XDG_CONFIG_HOME/wireplumber/30-baz.conf
- /usr/share/wireplumber/40-zzz.conf
This commit changes that so that it follows the hirerachy of the directories
first and then the order of the filenames, starting from the lowest priority
directory. So now for the same files you get:
- /usr/share/wireplumber/20-bar.conf
- /usr/share/wireplumber/40-zzz.conf
- /etc/wireplumber/10-foo.conf
- $XDG_CONFIG_HOME/wireplumber/30-baz.conf
In addition, the hash table is avoided, making things a bit more efficient
and the files are checked for G_FILE_TEST_IS_REGULAR
Shadowing of files still works the same, so in the above example
if /etc/wireplumber/30-baz.conf also exists, it is not returned
in the list, because it's shadowed by $XDG_CONFIG_HOME/wireplumber/30-baz.conf
This patch improves module-settings to load the settings schema into a
'schema-sm-settings' metadata for clients to know what values types and range
are accepted for each particular setting. This settings schema is defined in
the wireplumber.conf, under a new section called 'wireplumber.settings.schema'.
This doesn't need to be a singleton, since we have the core registration
API available publicly nowadays. Makes things more clean for the API,
following the pattern of WpPlugin and WpSiFactory and simplifies the
built-in settings component in the internal component loader :)
Similar to 'default.audio.sink', a setting from sm-settings should never be
removed when the associated persistent setting is removed. Only settings from
persistent-sm-settings can be removed, like 'default.configured.audio.sink'.
Do not send an error to the client when the target is not defined
and the 'node.linger' property is set.
It is not absolutely necessary that every node has a defined target.
We can have a 'Stream/Output/*' node which can be linked to
multiple 'Stream/Input/*' nodes and only the 'Stream/Input/*'
nodes have a defined target.
This patch removes the 'settings.persistent' option from the configuration as it
only allowed making settings persistent globally instead of individually. This
issue has been addressed in a simpler way by creating a 'persistent-sm-settings'
metadata. If a user wants to make a setting persistent, he can change the
'persistent-sm-settings' metadata object, if the user does not want to make a
persistent change, he can use the 'sm-settings' metadata object. Any changes in
the 'persistent-sm-settings' metadata will be also reflected in the 'sm-settings'
metadata object.
This is because 'filter-forward-format.lua' only configures nodes, and therefore
does not have anything to do with the linking logic. The setting has also been
renamed to 'node.filter.forward-format'.
This is because the associated node does not exist anymore. This change also
logs the session item Id when handling it, so that it is easy to know if the
unhandled session item was handled or not.
Since the loopback bluetooth source node is meant to be always used by
applications, this change hides the actual bluez sco-source node by marking
them as internal. This avoids showing 2 input devices in pavucontrol per BT
device if HSP/HFP profile is enabled.
