Once an object is removed from the registry, its id is invalidated and
can be later reused by other objects. WpGlobal objects may be
long-lived: e.g. those in tmp_globals may live over an add,remove,add
sequence for the same id, and a new WpGlobal must be used for the second
add. However, currently e.g. wp_registry_prepare_new_global may pick the
WpGlobal for a previously removed object from the tmp_globals list.
To address this, invalidate the WpGlobal id immediately when we get the
registry remove event.
* First of all, do not clear the stack... it's not necessary to do
so and it causes trouble if this function is called from within
itself, as it clears the stack of the previous context
* Then, do not stop/restart the garbage collector unless this is
the base call
Fixes#73
The spa_dict does not live outside of the scope it is created in
and so no metadata name is passed to the export function.
Use and initialize a variable outside of the scope instead.
Similar to the volume and latencyOffset we need parse, save and restore
the configured iec958Codecs on the node.
Pavucontrol will use the device-restore extension to set the configured
iec958Codecs on the Node/Route. This will make the node enumerate
audio/iec958 formats, which can be matched against streams that can
provide this format to configure passthrough.
Fixes#64
pw_log_set resets the log level of the logger to the Pipewire's current
level. Here, it's instead expected that the level is retained, so call
pw_log_set_level first.
It used to be that pw_init set the log level based on PIPEWIRE_DEBUG
value, but this is now done only when using Pipewire's default logger.
The idle callback may be called after the object manager has been
destroyed, or the object manager may be destroyed while emitting
one of the signals from the idle callback, so it needs to be ref'ed
while the callback is running. g_cclosure_new_object ensures that
in both cases the code behaves correctly.
It's not used elsewhere, so there is no good reason yet to expose it.
Besides, I expect that GLib will likely add a method in the future
to return the XDG_STATE_HOME (which is relatively new in the xdg spec)
* Make the flags public and give them nicer names
* Pass down the flags from the caller, so the caller can now explicitly
ask for looking into specific directories
* Rename the methods
* Remove and inline the wp_get_xdg_config_dir() method, since it's only
used internally
* Refactor the lookup dirs ordering to get both WIREPLUMBER_*_DIR env
variables to replace all the other directories. Previously, we were looking
for scripts in WIREPLUMBER_DATA_DIR, but we were also looking in /etc at
the same time (with precedence, even), which could result in unexpected
behaviour. Now, if a WIREPLUMBER environment variable is specified,
we only look in there.
This also corrects the logic of loading config files in m-lua-scripting.
Previously, if an error occured within the iteration function,
the error was not properly propagated to the caller because -EINVAL
was being added to nfiles instead of checked.
The previous approach to loading config files was to ask WP for the
directory and then search those for the config files. This patch changes the
approach - a caller now asks WP to search for a specific config file or
iterate over a config file directory.
This allows us to implement a directory lookup order, i.e.
"wireplumber.conf" may be in XDG_CONFIG_DIR, /etc/,
/usr/share and the first one found is used.
For configuration directories, the new method iterates over all matching
entries (files + directories) and invokes a callback for each entry.
This enables distributions to ship default files in /usr/share/wireplumber
but have admins and users override them on a local basis. For lua scripts in
particular, overriding a distribution-provided file with an empty file
effectively disables it, adding a file adds it in the right sort order.
Sometimes, especially when running the wireplumber daemon with valgrind, a new
global with the same Id as another old global owned by a proxy wants to be
exposed before the old proxy is destroyed. If this happens, instead of returning
with an assertion error, we remove the old global and we export the new one.
Globals can be removed by the object manager when their associated proxy is
currently being bound. Adding extra checks in wp_global_proxy_bin() to return
a transition error avoids binding the proxy when that happens.
If we don't remove the socket from epoll when the connection is lost, we risk
having the lost callback triggered more than once by epoll, creating race
condition in the unit test because more than 1 event happened. The epoll thread
and socket will be re-created again when re-connecting.
Note that we cannot destroy the epoll thread before triggering the lost
connection callback because we are running the callback in the epoll thread,
which is why removing the socket from epoll is the only way to make sure the
lost connection callback is only triggered once.
