Memory-to-memory devices have one video node, one internal control handler
but two vb2_queues (DMA engines). While often there is one buffer produced
for every buffer consumed, but this is by no means standard. E.g. deinterlacers
will produce on buffer for every two buffers consumed. Codecs that receive
a bit stream and can parse it to discover the framing may have no relation
between the number of buffers consumed and the number of buffers produced.
This poses a few problems for the Request API. Requiring that a request
contains the buffers for both output and capture queue will be difficult
to implement, especially in the latter case where there is no relationship
between the number of consumed and produced buffers.
In addition, userspace can make two requests: one for the capture queue,
one for the output queue, each with associated controls. But since the
controls are shared between capture and output there is an issue of
what to do when the same control is set in both requests.
I propose to restrict the usage of requests for m2m drivers to the output
queue only. This keeps things simple for both kernel and userspace and
avoids complex solutions.
Requests only make sense if there is actually configuration you can apply
for each buffer, and while that's true for the output queue, on the capture
queue you just capture the result of whatever the device delivers. I don't
believe there is much if anything you can or want to control per-buffer.
Am I missing something? Comments?
Regards,
Hans
