Re: Skype and libv4

[Lamarque Vieira Souza <lamarque@gmail.com>]

Em Wednesday 25 March 2009, Hans de Goede escreveu:
> On 03/24/2009 11:09 PM, Lamarque Vieira Souza wrote:
> > 	Hi,
> >
> > 	Applying this patch to libv4l makes Skype works with my webcam without
> > changing the driver. Do you think the patch is ok?
>
> No it is not ok, luckily I've also read the rest of this thread, where you 
write:
>  > 	I have found the problem. The vidioc_try_fmt_vid_cap function in the
>  > driver return -EINVAL if the fmt.pix.field is different from
>  > V4L2_FIELD_ANY or V4L2_FIELD_NONE. Skype seems to set this field as
>  > V4L2_FIELD_INTERLACED. Because of that libv4l assumes that all
>  > destination formats (YUV420 included) are invalid. Commenting this part
>  > of the driver makes Skype work and it is showing pictures. YES!!! :-)
>
> What you are seeing is a bug in the driver. VIDIOC_TRY_FMT should *never*
> return -EINVAL, except, and that is the only exception when it does not
> support the passed in type, so v4l2_format.type is something which is not
> supported, note that when vidioc_try_fmt_vid_cap is called the type is
> already checked (hence the _vid_ in the function name).

	Well, so there are some drivers in the kernel with this bug too (all in 
linux/drivers/media/video/ directory): meye.c and soc_camera.c (those two does 
exactly as zr364xx.c does); bt8xx/bttv-driver.c (this one returns -EINVAL if a 
combination of field (V4L2_FIELD_SEQ_TB) and flags (FORMAT_FLAGS_PLANAR) is 
invalid) or when field value is unknow, if it is unknow it really should 
return -EINVAL. Some drivers (cx18/cx18-ioctl.c, em28xx/em28xx-video.c, 
ivtv/ivtv-ioctl.c and stk-webcam.c) just set the field value to one they 
accept without even reading what value was passed to them and some 
(cx23885/cx23885-417.c and gspca/gspca.c) just ignores the field value 
returning what as passed to them. cx23885/cx23885-video.c, cx88/cx88-video.c 
and saa7134/saa7134-video.c will return -EINVAL if you pass 
V4L2_FIELD_ALTERNATE or V4L2_FIELD_SEQ_TB in the field field, if you pass 
V4L2_FIELD_ANY they will try to find one field value that is ok for them. 
s2255drv.c does more effort to validate the field value, in some cases it will 
return -EINVAL if it does not find a good value for the field field.

	Besides, vivi.c does something similar to zr364xx.c. It returns -EINVAL if 
the field value is different from V4L2_FIELD_ANY or V4L2_FIELD_INTERLACED. So 
if you pass V4L2_FIELD_NONE to vivi.c's try_fmt it will return -EINVAL too.

	What I am seeing here is that each driver behaves differently. So what is the 
correct behaviour?:

1. ignores the field value.
2. set the field value inconditionally to one value that the driver accepts.
3. only set the field value to one value that the driver accepts if 
V4L2_FIELD_ANY is passed to the driver (this one is what zr364xx.c and vivi.c 
do).

> When any member of fmt.pix. is not supported it should set it to something
> which it does support (and the app should check what it got) so the proper
> fix is to always set fmt.pix.field to V4L2_FIELD_NONE in the driver
> (V4L2_FIELD_ANY is an input only value, a format returned by a driver
> should never have V4L2_FIELD_ANY).

	So the behaviour number two is the correct one. So someone must change vivi.c 
as it is used as a guide to create new v4l2 drivers, although I still thinks 
the zr364xx.c and vivi.c do the logical thing: only changes the field value if 
the application allowed them to (when passing V4L2_FIELD_ANY).

-- 
Lamarque V. Souza
http://www.geographicguide.com/brazil.htm
Linux User #57137 - http://counter.li.org/

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list