A DMA buffer from a DRM device are typically accessed using API related
to a DRM device, e.g. Vulkan or EGL. To create such a context for using
with a PipeWire stream that passed DRM device DMA buffers applications
have so far usually guessed or made use of the same context as the
stream content will be presented. This has mostly been the Wayland
EGL/Vulkan context, and while this has most of the time worked, it's
somewhat by accident, and for reliable operation, PipeWire must be aware
of what DRM device a DMA buffer should be accessed using.
To address this, introduce device ID negotation, allowing sources and
sinks to negotiate what DRM device is supported, and what formats and
modifiers are supported by them.
This will allow applications to stop relying on luck or the windowing
system to figure out how to access the DMA buffers. It also paves the
way for being able to use multiple GPUs for different video streams,
depending on what the sources and sinks support.
Otherwise we might end up with partial channels when code doesn't
check the unpositioned flag. It's better to set everything to unknown
when there is a mismatch between channel count and layout.
Add a new SPA_TYPE_OBJECT_ParamDict object that contains a struct with
key/value pairs. We're using something similar for Tags but this is a
more generic version.
Make a new Capability param that uses the ParamDict object. This is
meant to be used to describe capabilities with the generic key/value
struct.
Make a new PeerParam object where the keys are generic ids of the peer
objects and the values any Pod. The idea is to use this object to store
a peer objects. Make some helpers to iterate the peers and their
objects.
Add a new PeerCapability param that uses the PeerParam object with
Capability objects. This can be used to send the collection of
Capabilities from all peers to a port. This is a bit like the tags but
in a more generic way. The tags could also be implemented in this new
generic way later.
Make the PeerFormats use the same PeerParam of Format objects.
The Capability param is set on ports. impl-link will collect all
Capability objects into a PeerCapability object and send this to the
peer. The difference with the Tag param is that these Capability params
are not in any way forwared on the node automatically (like what is done
in the loopback module) because they represent the capabilities of the
ports betweem the link.
Makes it possible to define audio channels and position with a
predefined layout string.
It is easier and less error prone to say "5.1" than to spell out
[ FL FR FC LFE RL RR ].
AUX channels have a special syntax. AUX<N> will make <N> AUX
channels. Easier to say AUX128 than to write an array with the
128 AUX channels.
The behavior before b8eeb2db45 was that spa_audio_info_raw_update()
always sets audio.channels when audio.position is updated. The new
behavior does not set audio.channels when parsing audio.position.
This breaks things e.g. when combine-sink and loopback nodes are created
with only audio.position specified.
Restore the previous behavior.
Remove the SPA_AUDIO_MAX_POSITION define and use the
SPA_AUDIO_MAX_CHANNELS again.
Make a compile time define to override the default max channels of 64.
Make sure we compile the SPA library with the default 64 channels. If
you use the SPA library on a spa_audio_info you will get 64 channel
support, like before. If you want more channels, you will need to make
a padded structure or redefine the MAX_CHANNELS before you use the
spa_audio_info structures. You can use the padded structure with the
new functions that take the structure size.
With the extra checks in the parsing code, we avoid making a
valid spa_audio_info with too many channels that don't fit in the
structure. This means that code that receives a spa_audio_info can
assume there is enough padding for all the channels.
Add functions that take the size of the spa_audio_info struct in various
functions. We can use this to determine how many channels and channel
positions we can store.
Error out if we try to use more channels than we can fit positions. This
is probably the safest thing to do because most code will blindly try to
get the positions without checking the channel count.
Make sure we also propagate errors to the callers.
Parse the audio.position spec completely so that we have the right
number of channels but only store the first max_position channels.
Also rename some field to make it clear that this is about the max
number of channel positions.
Add a new SPA_AUDIO_MAX_POSITION constant with the maximum number of
channel positions that can be kept in the various audio_info structures.
Repurpose the SPA_AUDIO_MAX_CHANNELS as a suggestion for applications
for the max allowed number of channels in the system. Make it possible
to make this a compile time constant.
Add a function that accepts the size of the position array when reading
the audio positions. This makes it possible to decouple the position
array size from SPA_AUDIO_MAX_CHANNELS.
Also use SPA_N_ELEMENTS to pass the number of array elements to
functions instead of a fixed constant. This makes it easier to change
the array size later to a different constant without having to patch up
all the places where the size is used.
Define some rules for how the position information works for channels >
SPA_AUDIO_MAX_CHANNELS. We basically wrap around and incrementing the
AUX channel counters. Make a function to implement this.
A fixed channel count makes no sense with an entity based 3D audio format
like MPEG-H, because MPEG-H decoders do not simply decode; they
"spatialize" the entities, meaning that said entities are decoded and
rendered accordingto the needs of the target playback system and its
channel count.
Add a new features property to the metadata param. This should be
of type CHOICE_FEATURES_Int and should contain the extra features
supported by this metadata.
Make a special features metadata type that is a combination of the
metadata type in the upper 16 bits and the features for that type in the
lower 16 bits. Make a function to search if a type has certain feature
bits.
On the server, when negotiating buffers and metadata, check the result
of the features after filtering and if they are not 0, place them as
0 sized extra feature metadata on the buffer.
Add some metadata features for the sync_timeline, one that specifies
that the RELEASE flag is supported. With this in place, a producer can
see if a consumer supports the UNSCHEDULED_RELEASE flag.
See #4885
Make a new body.h file with some functions to deal with pod and their
body. Make the iter.h functions use mostly this.
Rework the parser so that it only uses body.h functions. With the separation
of pod+body, we can read and verify the pod once and then use the
verified copy to handle the rest of the body safely.
We do this because iter.h only works in pods in memory that doesn't change
because it is vulnerable to modifications of the data after verifying it.
The new parser is not vulnerable to this and will not cause invalid
memory access when used on shared memory. There is however no need for
atomic operations to read the headers, whever is read is either valid
and useable of invalid and rejected.
See #4822
Add the missing type info for:
* SPA_FORMAT_VIDEO_colorRange
* SPA_FORMAT_VIDEO_colorMatrix
* SPA_FORMAT_VIDEO_transferFunction
* SPA_FORMAT_VIDEO_colorPrimaries
Properties of type Id should have a type of the enum with the possible
values associated with them.
The other types that don't have a fixed enumeration but are usually
mapped to some constant/description with PropInfo should be Int.
Fixes!2399
Including C headers inside of `extern "C"` breaks use from C++. Hoist
the includes of standard C headers above the block so we don't try
to mangle the stdlib.
I initially tried to scope this with a targeted change but it's too
hard to do correctly that way. This way, we avoid whack-a-mole.
Firefox is working around this in their e21461b7b8b39cc31ba53c47d4f6f310c673ff2f
commit.
Bug: https://bugzilla.mozilla.org/1953080
