Re: [Workshop-2011] RFC: V4L2 API ambiguities

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 08/14/2012 02:00 AM, Laurent Pinchart wrote:
> Hi Hans,
>
> On Monday 13 August 2012 15:13:34 Hans de Goede wrote:
>
> [snip]
>
>>> 4) What should a driver return in TRY_FMT/S_FMT if the requested format is
>>>      not supported (possible behaviours include returning the currently
>>>      selected format or a default format).
>>>
>>>      The spec says this: "Drivers should not return an error code unless
>>>      the input is ambiguous", but it does not explain what constitutes an
>>>      ambiguous input. Frankly, I can't think of any and in my opinion
>>>      TRY/S_FMT should never return an error other than EINVAL (if the
>>>      buffer type is unsupported) or EBUSY (for S_FMT if streaming is in
>>>      progress).
>>>
>>>      Returning an error for any other reason doesn't help the application
>>>      since the app will have no way of knowing what to do next.
>>
>> Ack on not returning an error for requesting an unavailable format. As for
>> what the driver should do (default versus current format) I've no
>> preference, I vote for letting this be decided by the driver
>> implementation.
>
> That's exactly the point that I wanted to clarify :-) I don't see a good
> reason to let the driver decide on this, and would prefer returning a default
> format

I see.

> as TRY_FMT would then always return the same result for a given input
> format regardless of the currently selected format.

That argument makes sense, so ack from me on always returning a default format.

Regards,

Hans