The purpose is to wrap some utilities that pipewire provides that use JSON.
Start by wrapping pw_conf_match_rules(), which despite its name, it has nothing
to do with the configuration object. It operates directly on JSON and can be
useful to work with match rules outside the context of configuration files.
This is needed for wireplumber to start up correctly in the meson
devenv when built as a subproject of pipewire. The reason for this
is that the value set for `PIPEWIRE_CONFIG_DIR` in the wireplumber
meson build file will be overriden when the pipewire meson files
set up another devenv with its own `PIPEWIRE_CONFIG_DIR`.
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
Calling functions on test server must lock the thread loop, otherwise
the concurrency causes corruptiont in module-protocol-native and you get
bogus messages etc.
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.
Previously, the `deps` variable was reused for parsing
the required and wanted dependencies of a component,
which lead to the old value allocated here:
if (wp_spa_json_object_get (json, "requires", "J", &deps, NULL)) {
being leaked when a bit later
if (wp_spa_json_object_get (json, "wants", "J", &deps, NULL)) {
succeeded.
Fix that by using two separate variables.
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 reverts commit 2ae1b3cbd9.
This is not a good API. It was only allowed temporarily in 0.4.15
to get things done. We should approach this properly in 0.5
This reverts commit 9def3f96d2.
This was never a good idea, as it turns out. It was not used in practice because
it was breaking other things (see 370b692933)
and now it appears to be causing more problems in Lua object managers that don't
install because they are waiting for inactive links to become active.
Fixes: #518
A core sync is not really necessary here because whatever objects the remote
pipewire daemon has to announce have already been sent to us on a message
and this message is already being processed at this point. This means, we are
not going to be returning to the main loop until all the new objects have been
announced and therefore placed into the tmp globals array. So, we can also use
an idle callback and achieve the same effect of slightly delaying until all
new globals have been announced.
With an idle callback, we can be more agile and add those new objects immediately
after the message has been processed instead of waiting for a pw_core_sync()
reply, which will come in the next message.
This fixes an odd failure of the si-standard-link test after applying the fix
for #517, which was caused by the fact that the test was previously relying on
a delay caused by some unrelated globals being prepared in the object manager
that tries to verify the graph state. After those globals were removed from the
internal preparation queue, the test would fail to detect the link objects
because they were stuck in the tmp_globals array for too long.
With the previous check, any global matching either the type or the global
properties of the interest would be considered for inclusion in the object
manager and would be prepared only to fail the same check later.
The correct way to check is (variable & (X|Y) == (X|Y)), which is what
SPA_FLAG_IS_SET() expands to.
Fixes#517
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.
In conf_apply_rules, check input argument is a table before assuming it
is and potentially crashing.
Add check also in wplua_table_to_properties to avoid similar bugs.
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.
