+ rename FEATURE_CONTROLS to FEATURE_PROPS
+ add accessor for the standard spa_param_info (info->params)
+ hide the low-level params API that nobody uses
by using G_TYPE_NONE (== 1), we can pass this in the log handler
to point out the fact that we expected something but it's null
As a bonus, a null object always gets printed in red because that's
the first color in object_colors
This makes WIREPLUMBER_DEBUG behave just like PIPEWIRE_DEBUG.
Same levels, same syntax, easier for users.
ERROR & CRITICAL are always printed, as they should; there is no point
in disabling them, since:
- ERRORs are always fatal and should never ever happen
- CRITICALs are assertion failures and indicate bugs that need to be fixed
* use a short level name, like pipewire does
* color the timestamp to compensate for the loss of the visible level name
* use 18 chars for the category
object managers that are registered a bit early (such as the one in
wireplumber-cli) have no use if they are declared as installed before
any globals appear. After the initial registry startup, there should
be at least 1 global, the core (id=0), so even if this client has
no access to any object, the object manager should be able to
finish its installation successfully
Features are flags, therefore we must NEVER use them without a shift,
otherwise bad mistakes happen, like the previous mistake of declaring
WP_SESSION_FEATURE_LINKS as the number after WP_SESSION_FEATURE_ENDPOINTS,
which ended up being (WP_SESSION_FEATURE_ENDPOINTS | WP_PROXY_FEATURE_PW_PROXY)
and it was always becoming available together with the ENDPOINTS feature.
The GLib error level is fatal, but pipewire doesn't use it that way.
Also, the GLib critical level is meant only for programming errors
(assertions) and not for runtime errors. warn & msg levels really
fit well with the error & warn, as they are being used in pipewire
currently.
It is a valid use case to do things like call wp_session_item_export()
from within the async ready callback of _activate(), and it's not
possible unless the ACTIVATING flag has been cleared first.
To do this, use a GCClosure to wrap the callback and install marshal
guards, which are called before and after the callback, to modify
the flags.
We can now call wp_proxy_request_destroy() on endpoint links and
the WpImplEndpointLink together with the session item that created
it will be cleaned up
When a pw_global is removed on the server (by pw_registry_destroy() or other
means), it triggers the proxy removed & the registry global_remove callbacks,
but it does not necessarily destroy the pw_proxy.
For client proxies, we were previously destroying them by unrefing the WpProxy
in wp_global_rm_flags(), since the global was not "owned" by the WpProxy.
For impl proxies, we were not doing anything, as we expected that it would
only be removed from the registry if the local WpProxy was destroyed first.
This is not always the case, though, as the server or another client may
request to destroy this proxy with pw_registry_destroy()
Now we always destroy the pw_proxy as soon as it is removed from the registry,
no matter if it was a client or an impl proxy. If it was an impl proxy,
the WpProxy will continue to live and it's up to the code that created it
to handle the "pw-proxy-destroyed" signal and do something meaningful.
If it was a client proxy, the global will still unref the WpProxy right after
destroying the pw_proxy and there is no change in behavior.
