Re: [media-workshop] Agenda for the Edinburgh mini-summit

[Hans Verkuil <hverkuil@xs4all.nl>]

On 08/31/2013 10:36 PM, Guennadi Liakhovetski wrote:
> On Sat, 31 Aug 2013, Laurent Pinchart wrote:
> 
>> Hi Guennadi,
>>
>> On Saturday 31 August 2013 20:38:54 Guennadi Liakhovetski wrote:
>>> On Sat, 31 Aug 2013, Hans Verkuil wrote:
>>>> On 08/30/2013 03:01 PM, Hans Verkuil wrote:
>>>>> OK, I know, we don't even know yet when the mini-summit will be held but
>>>>> I thought I'd just start this thread to collect input for the agenda.
>>>>>
>>>>> I have these topics (and I *know* that I am forgetting a few):
>>
>> [snip]
>>
>>>>> Feel free to add suggestions to this list.
>>>>
>>>> I got another one:
>>>>
>>>> VIDIOC_TRY_FMT shouldn't return -EINVAL when an unsupported pixelformat is
>>>> provided, but in practice video capture board tend to do that, while
>>>> webcam drivers tend to map it silently to a valid pixelformat. Some
>>>> applications rely on the -EINVAL error code.
>>>>
>>>> We need to decide how to adjust the spec. I propose to just say that some
>>>> drivers will map it silently and others will return -EINVAL and that you
>>>> don't know what a driver will do. Also specify that an unsupported
>>>> pixelformat is the only reason why TRY_FMT might return -EINVAL.
>>>>
>>>> Alternatively we might want to specify explicitly that EINVAL should be
>>>> returned for video capture devices (i.e. devices supporting S_STD or
>>>> S_DV_TIMINGS) and 0 for all others.
>>>
>>> Just to make sure I understand right - that kind of excludes cameras,
>>> right? Still, even for (other) video capture devices, like TV decoders, is
>>> there a real serious enough reason to _change_ the specs, which says
>>>
>>> http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-fmt.html
>>>
>>> EINVAL
>>>
>>>     The struct v4l2_format type field is invalid or the requested buffer
>>> type not supported.
>>
>> I think Hans meant unsupported fmt.pix.pixelformat (or the equivalent for 
>> multiplane) values.
> 
> Good, then I understood him correctly :)
> 
>> For instance the uvcvideo driver will return a default 
>> fourcc if an application tries an unsupported fourcc,
> 
> Yes, that's what I would do too and that's what the spec dictates.
> 
>> some other drivers 
>> return -EINVAL.
> 
> that just seems plain wrong to me. So, as I said, to not break the 
> userspace we can extend the specs, but not prohibit the currently defined 
> behaviour. So, that last option:
> 
>>>> Alternatively we might want to specify explicitly that EINVAL should be
>>>> returned for video capture devices (i.e. devices supporting S_STD or
>>>> S_DV_TIMINGS) and 0 for all others.
> 
> I'm not sure I like a lot, unless those drivers are very special and they 
> all already behave like that.

Almost (have to check though) all TV capture drivers behave like that, yes.
Very unfortunate.

On the other hand webcam apps must assume that TRY_FMT will just map an unsupported
pixel format to a valid pixel format since that is what uvc does. And a webcam app
that doesn't support uvc can't be called a webcam app :-)

Regards,

	Hans

> Thanks
> Guennadi
> 
>>> If we have a spec, that says A, and some drivers drivers do A, but others
>>> do B, and we want to change the specs to B? Instead of either changing the
>>> (wrong) drivers to A (yes, some applications expect that wrong behaviour)
>>> or at least extending the spec to allow both A and B?
>>
>> -- 
>> Regards,
>>
>> Laurent Pinchart
> 
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
>