[libcamera-devel,RFC,v8,0/1] Virtio video device specification
mbox series

Message ID 20230629144915.597188-1-Alexander.Gordeev@opensynergy.com
Headers show
Series
  • Virtio video device specification
Related show

Message

Alexander Gordeev June 29, 2023, 2:49 p.m. UTC 
Hi,

This is the 8th version of virtio-video device patch. Feedback would be very
appreciated.

The main change coming with this draft is the introduction of background
operations and delayed responses to commands (the term is taken from the SCMI
spec) over eventq. Now most of the commands work like this. The only
exceptions are STREAM_CREATE and RESOURCE_ATTACH_BACKING commands. This should
help avoid commandq descriptors exhaustion. Also I introduced "in band" and
"out of band" handling of SET_PARAMS command. Out of band is the way how it
was done before i.e. the command is handled immediately after dequeuing from
commandq. In band means putting it into device's INPUT queue so that it can
be executed precisely after a certain input resource and before the next one.
These two changes allowed me to represent the events as a custom case of the
delayed responses. Also this enables processing resolution changes embedded in
the stream and coming from outside in the same way. I think this makes it
possible to implement V4L2 Requests API.

Questions for discussion/roadmap:
1. It looks like the current way of describing the device capabilities is not
very well extendable. I'd like to change it again. The goal is that after
adding new generic parameters/new codecs/new codec parameters and covering
them with the feature flags the format of the device response doesn't depend
that much on the enabled flags. My current idea is to convert this into a
serie of descriptors with offsets and sizes, so that the device can then
simply adjust offsets and sizes, but keep that layout the same. Any ideas here
would be appreciated.
2. Since draft v7 the device is expected to provide all and every one of its
capabilities as a response to the DEVICE_QUERY_CAPS command. Maybe the device
shouldn't adjust the parameters itself now?
3. I think the last piece, that is missing completely, is QoS. How can the
device indicate to the driver, that it is saturated? How could the device be
shared between multiple guests in a fair way?

Full PDF: https://drive.google.com/file/d/1uPg4kxThlNPBSiC4b5veyFz4OFGytU7v/view?usp=sharing
PDF with the video section only: https://drive.google.com/file/d/1iW3MbseRZLovlxpc4XAF8VTvhQ_Tww6q/view?usp=sharing

Changelog v7 -> v8:
* Added the delayed responses to commands sent on the eventq.
* Added the in band STREAM_SET_PARAMS command handling.
* Implemented device events using the newly added delayed responses.

Alexander Gordeev (1):
  virtio-video: Add virtio video device specification

 conformance.tex                           |    4 +
 content.tex                               |    1 +
 device-types/video/description.tex        | 2040 +++++++++++++++++++++
 device-types/video/device-conformance.tex |   22 +
 device-types/video/driver-conformance.tex |   16 +
 introduction.tex                          |   21 +
 6 files changed, 2104 insertions(+)
 create mode 100644 device-types/video/description.tex
 create mode 100644 device-types/video/device-conformance.tex
 create mode 100644 device-types/video/driver-conformance.tex