Correct sequencing of usage of DRM writeback connector

[Hoosier, Matt]

Hi,

There is a discussion ongoing over in the compositor world about the implication of this cautionary wording found in the documentation for the DRM_MODE_CONNECTOR_WRITEBACK connectors:

>  *  "WRITEBACK_OUT_FENCE_PTR":
>  *	Userspace can use this property to provide a pointer for the kernel to
>  *	fill with a sync_file file descriptor, which will signal once the
>  *	writeback is finished. The value should be the address of a 32-bit
>  *	signed integer, cast to a u64.
>  *	Userspace should wait for this fence to signal before making another
>  *	commit affecting any of the same CRTCs, Planes or Connectors.
>  *	**Failure to do so will result in undefined behaviour.**
>  *	For this reason it is strongly recommended that all userspace
>  *	applications making use of writeback connectors *always* retrieve an
>  *	out-fence for the commit and use it appropriately.
>  *	From userspace, this property will always read as zero.

The question is whether it's realistic to hope that a DRM writeback connector can produce results on every frame, and do so without dragging down the frame-rate for the connector.

The wording in the documentation above suggests that it is very likely the fence fd won't signal userspace until after the vblank following the scanout during which the writeback was applied (call that frame N). This would mean that the compositor driving the connector would typically be unable to legally queue a page flip for frame N+1.

Is this the right interpretation? Is the writeback hardware typically even designed with a streaming use-case in mind? Maybe it's just intended for occasional static screenshots.

Matt Hoosier