| Message ID | 20260703224817.15650-3-ballen4705@googlemail.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series |
|
| Related | show |
Hi 2026. 07. 04. 0:48 keltezéssel, Bruce Allen írta: > Describe how applications read SensorSequence from Request::metadata() and > how it differs from per-buffer FrameMetadata::sequence. > > Signed-off-by: Bruce Allen <ballen4705@googlemail.com> > --- > Documentation/guides/application-developer.rst | 26 ++++++++++++++++++++++ > 1 file changed, 26 insertions(+) > > diff --git a/Documentation/guides/application-developer.rst b/Documentation/guides/application-developer.rst > index a9620ca..77b4135 100644 > --- a/Documentation/guides/application-developer.rst > +++ b/Documentation/guides/application-developer.rst > @@ -469,6 +469,32 @@ and the bytes used by planes. > seq: 000040 bytesused: 1843200 > seq: 000042 bytesused: 1843200 > > +Request metadata > +~~~~~~~~~~~~~~~~ I feel like this should be a subheading under "Handle request completion events", and at the very of it, just before the "Request queueing" header. > + > +Completed requests also expose metadata as a :doxy-pub:`ControlList` through > +:doxy-pub:`Request::metadata()`. Pipeline handlers populate this list with > +controls defined as ``direction: out`` in the control definition YAML files. I would write something like: "Only controls where :doxy-pub:`ControlId::direction()` signals :doxy-pub:`ControlId::Direction::Out` are returned as metadata." because the yaml file is a completely internal implementation detail. > + > +Common entries include :doxy-pub:`controls::SensorTimestamp`, > +:doxy-pub:`controls::FrameWallClock`, and :doxy-pub:`controls::SensorSequence`. > +The latter reports the sequence number from the sensor-facing capture device > +(for example the CSI-2 receiver or V4L2 video node) for the frame associated > +with the request. > + > +While per-buffer :doxy-pub:`FrameMetadata::sequence` identifies frames in each > +completed stream, ``SensorSequence`` reflects the sensor-side capture path. If > +the value increases by more than one between consecutive completed requests, > +frames were not captured before the earlier request finished. This complements > +sequence numbers derived from request delivery and is intended for diagnosing > +frame continuity. > + > +.. code:: cpp > + > + const ControlList &metadata = request->metadata(); > + if (auto seq = metadata.get<int64_t>(controls::SensorSequence)) I would drop the `<int64_t>` part. And I also feel like most of this `SensorSequence`-specific info should be in the documentation of the `SensorSequence` control itself. Regards, Barnabás Pőcze > + std::cout << " sensor sequence: " << *seq << std::endl; > + > A completed buffer contains of course image data which can be accessed through > the per-plane dma-buf file descriptor transported by the ``FrameBuffer`` > instance. An example of how to write image data to disk is available in the
Hi Barnabás, thanks very much for the helpful feedback. Your points (both here and in the second email) are all sensible. I'll upload a revised version of the patch this weekend. Cheers, Bruce On 29.07.26 11:21, Barnabás Pőcze wrote: > Hi > > 2026. 07. 04. 0:48 keltezéssel, Bruce Allen írta: >> Describe how applications read SensorSequence from Request::metadata() >> and >> how it differs from per-buffer FrameMetadata::sequence. >> >> Signed-off-by: Bruce Allen <ballen4705@googlemail.com> >> --- >> Documentation/guides/application-developer.rst | 26 ++++++++++++++++ >> ++++++ >> 1 file changed, 26 insertions(+) >> >> diff --git a/Documentation/guides/application-developer.rst b/ >> Documentation/guides/application-developer.rst >> index a9620ca..77b4135 100644 >> --- a/Documentation/guides/application-developer.rst >> +++ b/Documentation/guides/application-developer.rst >> @@ -469,6 +469,32 @@ and the bytes used by planes. >> seq: 000040 bytesused: 1843200 >> seq: 000042 bytesused: 1843200 >> +Request metadata >> +~~~~~~~~~~~~~~~~ > > I feel like this should be a subheading under "Handle request completion > events", > and at the very of it, just before the "Request queueing" header. > > >> + >> +Completed requests also expose metadata as a :doxy-pub:`ControlList` >> through >> +:doxy-pub:`Request::metadata()`. Pipeline handlers populate this list >> with >> +controls defined as ``direction: out`` in the control definition YAML >> files. > > I would write something like: > > "Only controls where :doxy-pub:`ControlId::direction()` > signals :doxy-pub:`ControlId::Direction::Out` are returned as metadata." > > because the yaml file is a completely internal implementation detail. > >> + >> +Common entries include :doxy-pub:`controls::SensorTimestamp`, >> +:doxy-pub:`controls::FrameWallClock`, and :doxy- >> pub:`controls::SensorSequence`. >> +The latter reports the sequence number from the sensor-facing capture >> device >> +(for example the CSI-2 receiver or V4L2 video node) for the frame >> associated >> +with the request. >> + >> +While per-buffer :doxy-pub:`FrameMetadata::sequence` identifies >> frames in each >> +completed stream, ``SensorSequence`` reflects the sensor-side capture >> path. If >> +the value increases by more than one between consecutive completed >> requests, >> +frames were not captured before the earlier request finished. This >> complements >> +sequence numbers derived from request delivery and is intended for >> diagnosing >> +frame continuity. >> + >> +.. code:: cpp >> + >> + const ControlList &metadata = request->metadata(); >> + if (auto seq = metadata.get<int64_t>(controls::SensorSequence)) > > I would drop the `<int64_t>` part. And I also feel like most of this > `SensorSequence`-specific > info should be in the documentation of the `SensorSequence` control itself. > > > Regards, > Barnabás Pőcze > > >> + std::cout << " sensor sequence: " << *seq << std::endl; >> + >> A completed buffer contains of course image data which can be >> accessed through >> the per-plane dma-buf file descriptor transported by the >> ``FrameBuffer`` >> instance. An example of how to write image data to disk is available >> in the >
diff --git a/Documentation/guides/application-developer.rst b/Documentation/guides/application-developer.rst index a9620ca..77b4135 100644 --- a/Documentation/guides/application-developer.rst +++ b/Documentation/guides/application-developer.rst @@ -469,6 +469,32 @@ and the bytes used by planes. seq: 000040 bytesused: 1843200 seq: 000042 bytesused: 1843200 +Request metadata +~~~~~~~~~~~~~~~~ + +Completed requests also expose metadata as a :doxy-pub:`ControlList` through +:doxy-pub:`Request::metadata()`. Pipeline handlers populate this list with +controls defined as ``direction: out`` in the control definition YAML files. + +Common entries include :doxy-pub:`controls::SensorTimestamp`, +:doxy-pub:`controls::FrameWallClock`, and :doxy-pub:`controls::SensorSequence`. +The latter reports the sequence number from the sensor-facing capture device +(for example the CSI-2 receiver or V4L2 video node) for the frame associated +with the request. + +While per-buffer :doxy-pub:`FrameMetadata::sequence` identifies frames in each +completed stream, ``SensorSequence`` reflects the sensor-side capture path. If +the value increases by more than one between consecutive completed requests, +frames were not captured before the earlier request finished. This complements +sequence numbers derived from request delivery and is intended for diagnosing +frame continuity. + +.. code:: cpp + + const ControlList &metadata = request->metadata(); + if (auto seq = metadata.get<int64_t>(controls::SensorSequence)) + std::cout << " sensor sequence: " << *seq << std::endl; + A completed buffer contains of course image data which can be accessed through the per-plane dma-buf file descriptor transported by the ``FrameBuffer`` instance. An example of how to write image data to disk is available in the
Describe how applications read SensorSequence from Request::metadata() and how it differs from per-buffer FrameMetadata::sequence. Signed-off-by: Bruce Allen <ballen4705@googlemail.com> --- Documentation/guides/application-developer.rst | 26 ++++++++++++++++++++++ 1 file changed, 26 insertions(+)