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.
The filter's destination target was not being found properly due to iterating
the matching rules table with ipairs instead of pairs... the later is meant to
be used with JSON objects. In addition, the filters were not being re-evaluated
and linked properly when a device node was removed, this is because of a typo in
the find-best-target.lua script.
See #501
This solves the problem of linkables not created for libcamera nodes. It makes
sense to run monitors towards the end when rest of the system is really
waiting for them.
A profile is a list of features set to required/optional/disabled
which governs which components are getting loaded, given a static
components list with well-defined dependencies
Each component can now list required and optional dependencies,
using the component feature names to match other components.
In addition, each component feature can be declared as required, optional
or disabled, making optional components easier to deal with.
The component flags (ifexists, nofail) have been removed.
Using virtual components, this system also allows easier customization
of which components should be loaded for a specific configuration,
without requiring the user to copy the list of components and edit it.
Also bump the required glib version to 2.68 for g_assert_cmpstrv()
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()
Now that we have proper module load order, we can have this shared
dbus connection in a module instead of the library. The module has
to be loaded before any other modules that need it, obviously.
Disable bluez5.auto-connect.
It makes PW to try connect to all locally known BT audio devices on
start, which is in general not a good thing to do.
Some BT adapters are not capable of simultaneous audio streaming and
scanning for connections (e.g Raspberry Pi builtin BT, probably more),
so audio stutters until adapter/kernel give up trying to connect to
devices that cannot be reached.
Disabling it makes devices to not reconnect on user VT switch, but also
that we should only do for devices that were connected when logind
switched.
After a timeout, it's possible that something else may have
destroyed the node already. This can happen for example with virtual
sinks that were created from another process.
Fixes: #467
libcamera uses namespaces to sandbox IPA (Image Processing Algorithm)
modules because they are sometimes proprietary binary blobs. The
RestrictNamespaces option in Wireplumber's systemd service breaks this
sandboxing when libcamera is loaded via the libcamera SPA module, so
cameras requiring an IPA do not work.
This commit removes RestrictNamespaces so that the sandboxing works
again. I've confirmed that after this change wireplumber works with
libcamera with an IPA module.
Resolves#466
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
