Refuse to run when we run in the daemon, we can't really do a blocking
connect to the daemon from its main thread.
Also refuse to run when we detect an old pipewire libaray. Blocks the
case where some app linked against 0.2 wants to use the replacement
libjack.so.
This is necessary on some 32-bit architectures that implement atomic
operations on 64-bit quantities as library calls, including Debian's
armel and mipsel ports.
Signed-off-by: Simon McVittie <smcv@debian.org>
Make sure we emit the buffer callback either from the calling thread
or from the thread_loop. Mark the callback as pending and don't call
the process function until the callback has been handled.
Only append app name and node name when they are different
Use / to separate app name from node name because : is used to
separate client name from port name.
Only emit callbacks when something changed.
When setting a value, first update the local store. This triggers
the emit from the calling thread (as expected by jack clients) and
when the update arrives from the server, it will not emit the callback
anymore because the value didn't change.
This is easier to handle in general and we should not use the name
as a unique id. If the session manager wants to save things, it can
use whatever fields it wants from the object to create a unique
persistent name.
Let the jack client make passive links when the PIPEWIRE_LINK_PASSIVE
variable is set. Makes it possible to start qsynth with passive links
so that it suspends when not in use.
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>
