This is a new rules section that allows defining rules to modify
component definitions. This is useful to add repetitive dependencies,
for example, as in the case of "type = script/lua" that always requires
the "support.lua-scripting" feature. This can also be useful to modify
other component properties, such as the arguments, in overriding
configuration files, without needing to redefine the whole components
section.
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.
Do not continue iteration over all other profiles when
we found the profile set in the 'device.profile' property.
In other case we would overwrite this profile when
we find a best_profile.
Sometimes, it may be necessary to pass arguments in to a
Pipewire module being loaded. Allow this to be done using
the same format as load_module()/load_optional_module().
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
Note: this requires all existing config files to be modified to follow
pipewire's rules syntax, with an "actions" object wrapping the
"update-props" object.
update the module-rt description and commented-out defaults to
reflect the addition of utilisation clamping to the module.
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
When set to 'true', the node will remain alive without any error produced if
it cannot be linked to its specified target; in all other cases, an error will
be produced and the node will be destroyed.
Two new properties are available to change the behavior of the linking policy:
- target.dont-fallback: when set to true, the node shouldn't be allowed to
fallback to another available target other than the one specified in the
target.object property or metadata.
- target.dont-move: when set to true, wireplumber should ignore the
target.object metadata, so that it isn't possible to dynamically move the node
to another target using metadata.
See #524
some hardware devices are never supposed to be accessed directly by
clients, and are designed under the assumption that they will be
front-loaded by some sort of DSP. add a hide_parent property
to policy-dsp and revoke all permissions to the bound node of a DSP
graph where this is set to prevent hardware misuse or damage by poorly
behaved/configured clients.
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
Try to connect to the default manager remote, before trying the default
remote.
Check libpipewire version is new enough to support setting arrays.
Bump Pipewire version to have pw_check_library_version.
This patch improves the smart filters unlinking logic by only unlinking smart
filters that are disabled, instead of any kind of filters. The patch also
removes redundant filter hooks.
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.
This patch updates the deprecated policy-bluetooth.lua script so that it works
with the current version. The script has been moved into the device sub-folder,
and renamed to autoswitch-blueooth-profile.lua. The settings-manager is also
used for the configuration, and the actual configuration has been moved from
linkind.conf to bluetooth.conf.
Handle client-requested and flatpak access on the session manager side.
Pipewire daemon doesn't know about the intended permission hierarchy, so
it is better done on the session manager side, where all the rules are.
The "default" access is used for normal clients, in the use case where
Pipewire server will not assign permissions itself but leaves it to the
session manager. In this use case only session manager has
"unrestricted".
Make "default" equal to "unrestricted" in the default access
configuration.
This allows users to enable/disable smart filter policy per filter. The property
is considered false by default, meaning that smart filter policy is disabled for
all filters by default.
I don't fully remember where this originates from, but it looks like
some sort of hack to workaround a race condition where the event handler
would try to iterate over items that were just created and were not yet
fully ready to be used.
Since all scripts run in a sandbox with their own global environment,
it means that they don't interfere with each other's global variables.
Therefore, all file-wide variables can be declared global without
any change in behavior. In my understanding, it is better to do so
because this means that any code accessing those variables is going
to access them directly from the global environment table with a simple
lookup rather than having each variable referenced in the local closure
of each function separately.
