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
