Fix up clients that say they have fixed properties while in fact
they are not. Assume that when there are alternatives, the property
was in fact not fixed.
When a resource is doing an operation that sets the client in the busy
state, make sure we unblock the client again when the resource is
destroyed before we could complete the operation or else the client
is stuck forever.
dup the fd when added to the outgoing buffer and close it againç
when sent. This ensures the fd remains valid in the buffer. A
quick add/remove of memory before a buffer flush could close the
fd before we can send it and then we get a bad fd and disconnect
the client.
When the proxy was removed, we remove the event listener and don't
set the proxy to NULL because the destroy event is not called anymore.
If we then call disconnect twice, we try to destroy the proxy again
and assert.
On GNU/Linux systems, the literal string '${LIB}' in dynamic linker
paths expands to "lib", a biarch libQUAL directory such as "lib64", or
a Debian-style multiarch directory such as "lib/x86_64-linux-gnu".
If we're installing libraries to such a directory, and we have both
word-sizes' compatibility libraries available, then pw-pulse can
use LD_LIBRARY_PATH='/usr/${LIB}/pipewire-0.3/pulse' to make both
i386 and x86_64 programs load the correct version.
Signed-off-by: Simon McVittie <smcv@debian.org>
LD_LIBRARY_PATH="/path/to/lib:" is interpreted as equivalent to
LD_LIBRARY_PATH="/path/to/lib:.", loading libraries from the current
working directory, which could lead to malicious libraries being loaded
if the current working directory is untrusted. To avoid this, only add
the current LD_LIBRARY_PATH to the new LD_LIBRARY_PATH if it is
actually set.
This commit also single-quotes the interpolated @VARIABLES@ so that
their values can contain shell special characters (other than single
quotes).
Signed-off-by: Simon McVittie <smcv@debian.org>
Remove the extra proxy to the node, it's awkward and not needed.
pw_core_export() returns a handle to the remote object with the
interface of the factory.
If the node is destroyed, make sure the proxy doesn't access
it anymore.
If the handle is removed or destroyed, make sure we remove the
proxy related info around the node. Never destroy the proxy
ourselves, this is something the app needs to do when it is
ready.
due to usage of VK_ERROR_OUT_OF_POOL_MEMORY, VK_ERROR_INVALID_EXTERNAL_HANDLE,
VK_API_VERSION_1_1 and VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT
introduced in version 1.1.69
Signed-off-by: Martin Koch <martin.koch@ese.de>
Don't try to use the proxy destroy event to destroy the objects.
It is not called automatically anymore, only when we call
pw_proxy_destroy() ourselves.
Destroy the proxy objects when we destroy the session managed
object instead, either when the global is removed or when we
explicitly call _destroy()
Add an object free signal to clean up final resources after the
proxies have been destroyed, like closing libraries.
Track and destroy our link proxies.
