This variable describes whether we have systemd and libsystemd,
not just <systemd/sd-daemon.h>
While at it, sneak in a fix for the warning message:
"systemd should never ever be capitalized".
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Remove the hooks we installed on objects in the destroy/free event
or before calling _destroy. This is not really needed but it is
a nice thing to do because it calls the hook removed callbacks.
PIPEWIRE_CORE can be used to specify a server name.
PIPEWIRE_REMOTE can be used to specify what server name to
connect to.
Either use the absolute path of the name to create and connect
to a server, or use a relative path. For a relative path, the
server name will be completed by prefixing the following paths
in order:
PIPEWIRE_RUNTIME_DIR environment variable,
XDG_RUNTIME_DIR environment variable,
HOME environment variable,
USERPROFILE environment variable,
home directory as stored in the password database.
Fixes#259
First use the configured properties, then use the env variables.
Make the daemon use the env variable by default.
This makes it possible to start servers with PIPEWIRE_CORE env variable
names but still override with the command option.
Makes it possible to make apps connect to PIPEWIRE_REMOTE env by
default and allows you to override with the command option.
Send create_object error messages to the new resource id so that
the client can better know what proxy is failing.
Use resource_remove when create_object fails because the core will
already send a remove_id on failure.
Try to send other errors to the proxy that made the request if
possible.
Log an error when we send an error to the client so that we don't need
to log and error anymore.
Improve the error messages when we can
Move some warnings and errors to debug
The socket call does not terminate the string with '\0' so
we have to use the length explicitly.
Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Make it possible to pause emision of events from the core object.
This is interesting if we need to wait for completion of some operations
on another connection before resuming processing.
See #204
Don't pass pw_properties around when we simply need to pass around
config info, only use pw_properties when used to construct an object
that keeps the properties.
Move the core implementation to a separate file. Make a default
core object in the context.
Pass impl-core to server. We now tie the server to a core. Also
keep track of the core that a client connected to.
Fill the properties that we usually use to connect in the context
and copy them when a connection is made.
Use "internal" as the remote name to connect to the default
internal core.
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.
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.
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.
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.
Don't register in client_new() to make it possible to do other things
on the client before registering. Register the client in protocol-native
after we set up the events etc.
otherwise, if the access module blocks the client, the on_start
callback in the protocol is not called and there is no global,
which means the session manager cannot do anything to grant
permissions on this client and the client is blocked forever
Separate the session manager in a monitor and policy part.
The monitor manages the devices and endpoints.
The policy watches the nodes/ports/clients and applies the policy
of linking them.
Because both now have a separate connection, we can remove some
hacks in the protocol. When a remote was both the implementer and
user of an object we could get in a deadlock when the user was
blocked waiting and the implementator was blocked sending a reply.
We used to un-busy a client when it was expecting a reply from a
ping or sync for this reason.
Add and use some more keys for the endpoints and streams.
