doc: add some small docs updates

Note that the sync_timeline metadata might add 2 fds, which are then not
part of the dma-buf planes.
This commit is contained in:
Wim Taymans 2024-08-21 11:01:54 +02:00
parent f2f204d604
commit 8edb6fc8b2
2 changed files with 7 additions and 1 deletions

View file

@ -110,7 +110,9 @@ Check the type of the dequeued buffer. If its \ref SPA_DATA_MemFd or
\ref SPA_DATA_MemPtr use the fallback SHM import mechanism.
If it's \ref SPA_DATA_DmaBuf
get the DMA-BUF FDs (the plane count is encoded in the `n_datas` variable of the
`spa_buffer` struct) and import them with the graphics API.
`spa_buffer` struct) and import them with the graphics API. Note: that the n_datas
might also contain extra fds for things like sync_timelime metadata, you need
to take this into account when persing the planes.
Note: Some graphics APIs have separated functions for the modifier-less case
(`DRM_FORMAT_MOD_INVALID`) or are omitting the modifier, since it might be used

View file

@ -167,6 +167,10 @@ struct spa_meta_videotransform {
*
* Metadata to describe the time on the timeline when the buffer
* can be acquired and when it can be reused.
*
* This metadata will usually also require negotiation of 2 extra
* buffer datas of type SPA_DATA_SyncObj with 2 fds for the acquire
* and release timelines respectively.
*/
struct spa_meta_sync_timeline {
uint32_t flags;