On Tue, Aug 21, 2018 at 6:15 PM Tomasz Figa <tfiga@xxxxxxxxxxxx> wrote: > > On Wed, Aug 15, 2018 at 11:18 PM Hans Verkuil <hverkuil@xxxxxxxxx> wrote: > > > > On 15/08/18 14:11, Mauro Carvalho Chehab wrote: > > > Em Sat, 4 Aug 2018 15:50:04 +0200 > > > Hans Verkuil <hverkuil@xxxxxxxxx> 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
