On Tue, Aug 21, 2018 at 6:15 PM Tomasz Figa <tf...@chromium.org> wrote: > > On Wed, Aug 15, 2018 at 11:18 PM Hans Verkuil <hverk...@xs4all.nl> wrote: > > > > On 15/08/18 14:11, Mauro Carvalho Chehab wrote: > > > Em Sat, 4 Aug 2018 15:50:04 +0200 > > > Hans Verkuil <hverk...@xs4all.nl> escreveu: > > > > > >> Hi all, > > >> > > >> While the Request API patch series addresses all the core API issues, > > >> there > > >> are some high-level considerations as well: > > >> > > >> 1) How can the application tell that the Request API is supported and for > > >> which buffer types (capture/output) and pixel formats? > > >> > > >> 2) How can the application tell if the Request API is required as > > >> opposed to being > > >> optional? > > > > > > Huh? Why would it be mandatory? > > > > It is mandatory for stateless codecs: you can't use them without the > > Request API since > > each frame needs the state as well. If you could make a driver for a > > stateless codec > > without the Request API we wouldn't have had to spend ages on developing it > > in the first > > place, would we? :-) > > Technically, one could still do the synchronous S_EXT_CTRL, QBUF, > DQBUF, S_EXT_CTRL... loop, but I'm not sure if this is something worth > considering.
Having this option is useful for driver bringup at the very least. And why add artificial constraints if the two APIs are able to work independently, albeit in a sub-optimal way? > > [snip] > > >> Regarding point 3: I think this should be documented next to the pixel > > >> format. I.e. > > >> the MPEG-2 Slice format used by the stateless cedrus codec requires the > > >> request API > > >> and that two MPEG-2 controls (slice params and quantization matrices) > > >> must be present > > >> in each request. > > > > > > Makes sense to document with the pixel format... > > > > > >> I am not sure a control flag (e.g. V4L2_CTRL_FLAG_REQUIRED_IN_REQ) is > > >> needed here. > > > > > > but it sounds worth to also have a flag. > > > > I'll wait to get some more feedback. I don't have a very strong opinion on > > this. > > > > I don't see any value in a flag for codecs. Querying the controls for > the flag, if it's already required as a part of the Stateless Codec > Interface for given pixel format, would only mean some redundant code > both in kernel and user space. > > For other use cases, I'm not sure if we can say that a control is > really required in a request. I think it should be something for the > user space to decide, depending on the synchronization (and other) > needs of given use case. > > Best regards, > Tomasz