The proxy API is the one that we would like to expose for applications
and the other API is used internally when implementing modules or
factories.
The current pw_core object is really a context for all objects so
name it that way. It also makes it possible to rename pw_core_proxy
to pw_proxy later.
Implement the local-v4l2 example with a core-proxy connected to
a local instance. We can export and instantiate objects and
link nodes and ports without having to touch the implementations.
Always create a local server without any socket. We can use this
to create clients that connect locally (in-process), such as
the cli or any app that wants to create a local pipeline.
Also disconnect filters.
Ignore multiple destroy calls. This can happen when the protocol
destroys the core-proxy and some implementation cleanup code
does the same. The cleanup code can't reliably know about this
cleanup.
Remove the core_proxy from objects so that it doesn't try to use it
when it's being destroyed.
We need to recheck the core_proxy because it might have been removed
in the destroy signal.
The pw_remote object is really a wrapper around the pw_core_proxy.
The events it emits are also available in the core proxy and are
generally awkward to use.
With some clever new pw_core_proxy_* methods and a pw_core_connect
to create the core_proxy, we can convert all code away from pw_remote.
This is a first step in this conversion, using the pw_remote behind
the scenes. It leaks into some places because it really needs to become
its own struct in a next step.
Let the core load a set of default modules.
Add a key to control what default set to load, falling back to a
reasonable set. Make the daemon not load any set and rely on the
config script to load modules.
Make the core proxy available right after we called connect. This
makes it possible to avoid waiting for the remote state change and
start using the core_proxy right away.
Make the connection as soon as we create the client. We create it
without file descriptor and then set it when we connect. This
makes it possible to use the connection to queue messages before
we connect.
media-session: Wait for devices to appear and be bound before setting
the profile on the device. Then wait for all the nodes to appear
before attempting the create endpoints on the device.
Let the session manager monitor device objects as well.
Make the alsa-endpoint monitor a separate service instead of letting
the alsa-monitor call it directly. This means that it listens for
device objects and then tries to configure the endpoints when the
device profile is set to active. This does not work yet because we
can't link the nodes to the device yet because there is no way to know
what the global id is of the device we created.
Make sure implementations of objects run in a separate remote connection
because the main remote connection might block while waiting for a
return value from the implementation.
Trigger an object update after all object info is collected. We do this
by triggering a roundtrip after receiving the info event. When we get
the reply, we can assume all info is flushed. This includes the
parameters that we received.
