This also brings the advantage that all tools, examples, modules, components
can also be compiled standalone out-of-tree using libpipewire from the system
Make methods to load_config and load/save state. For now the config
and state directories are the same but it might not be. Implement
the search path for all config/state files as:
$XDG_CONFIG_HOME/[$prefix]/$name
$HOME/.config/[$prefix]/$name
$PIPEWIRE_CONFIG_DIR/pipewire/[$prefix]/$name
/etc/pipewire/[$prefix]/$name
Make some config files for jack and RT clients. Make pw-cat use the
client-rt config.
Use core state and config management in media-session.
Move all session manager state and config files to the build dir and
set the PIPEWIRE_CONFIG_DIR to this build dir.
Make pw_properties_new_string() work with a json object string.
This makes it possible to specify property strings as more complex
objects and escape characters.
Clear the hook before adding it so that we are sure the removed
callback doesn't contain garbage and cause a crash on disconnect.
Mark the removed and priv fields as private. Make sure to add the
removed callback after adding the hook.
Fixes a crash in kwin
Make sure the hook lists are emptied so that the removed callbacks
are called. The callers should really remove the hook they installed
themselves but this is a last chance to fix things up.
The __x86_64__ macro identifies a CPU family, and is unfortunately not
enough to identify a concrete ABI.
The normal x86_64 ABI that is used by practical Linux distributions is
LP64 (i.e. 32-bit int, and 64-bit long and pointer), and defines
__x86_64__ and __LP64__.
x32 is a niche ILP32 ABI (i.e. 32-bit int, long and pointer) for x86_64
CPUs, which has different struct sizes due to sizeof(long) and
sizeof(void *) being smaller. It defines __x86_64__ and __ILP32__.
Signed-off-by: Simon McVittie <smcv@debian.org>
This makes it easier to test PipeWire in its "as-installed" state,
for example in an OS distribution.
The .test metadata files in ${datadir}/installed-tests/${package} are
a convention taken from GNOME's installed-tests initiative, allowing a
generic test-runner like gnome-desktop-testing to discover and run tests
in an automatic way.
The installation path ${libexecdir}/installed-tests/${package} is also
a convention borrowed from GNOME's installed-tests initiative.
In addition to the automated tests, I've installed example executables
in the same place, for manual testing. They could be separated into
a different directory if desired, but they seem like they have more
similarities with the automated tests than differences: both are there
to test that PipeWire works correctly, and neither should be relied on
for production use. Some examples are installed in deeper subdirectories
to avoid name clashes.
Signed-off-by: Simon McVittie <smcv@debian.org>
This tests exporting a PW_TYPE_INTERFACE_Endpoint and binding
a proxy for it through the registry, verifying that info and params
are propagated properly from one to the other
This is more in line with wayland and it allows us to create new
interfaces in modules without having to add anything to the type
enum. It also removes some lookups to map type_id to readable
name in debug.
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.
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 it possible to know when a proxy is bound to a global id before
the global shows up in the registry. This makes it possible to match
locally created objects to the one appearing in the registry and
possibly avoid a second bind.
Remove some of the unused states in pw_stream. The app can know the
state by following the format and buffer events.
Make it possible to be notified of io are updates. This should make it
possible to follow the transport etc.
Make it possible to be notified of any param changes.
Rename finish_format to update_params because that is what it does.
Make this work in the same was as the filter: updating the params
removes all old params of the types and installs the new ones.
Don't get the Props and PropInfo from the node proxy, instead get them
directly from the adapter that we have locally. Update the controls
directly on the adapter instead of going to the server first.
