On 06/08/18 10:16, Paul Kocialkowski wrote: > Hi Hans and all, > > On Sat, 2018-08-04 at 15:50 +0200, Hans Verkuil wrote: >> 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? >> >> 3) Some controls may be required in each request, how to let userspace know this? >> Is it even necessary to inform userspace? >> >> 4) (For bonus points): How to let the application know which streaming I/O modes >> are available? That's never been possible before, but it would be very nice >> indeed if that's made explicit. > > Thanks for bringing up these considerations and questions, which perhaps > cover the last missing bits for streamlined use of the request API by > userspace. I would suggest another item, related to 3): > > 5) How can applications tell whether the driver supports a specific > codec profile/level, not only for encoding but also for decoding? It's > common for low-end embedded hardware to not support the most advanced > profiles (e.g. H264 high profile). Just to point out that this is unrelated to the Request API. I see this as a separate topic that is probably worth an RFC by itself. Regards, Hans
