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 buffertype not supported.
I think Hans meant unsupported fmt.pix.pixelformat (or the equivalent for multiplane) values. For instance the uvcvideo driver will return a default fourcc if an application tries an unsupported fourcc, some other drivers return -EINVAL.
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?