Hi Hans,

On Wednesday 12 November 2008, Hans de Goede wrote:
> Laurent Pinchart wrote:
> > Hi Filippo,
> >
> > On Wednesday 12 November 2008, Filippo Argiolas wrote:
>
> <snip>
>
> >> The webcam light never turns on, maybe something is failing with webcam
> >> initialization.
> >
> > I've compared the two traces (both kernel log messages and libv4l) and
> > they are identical for the initialisation part.
> >
> > Two things bother me. First of all, libv4l spams the the driver (and thus
> > the camera) with VIDIOC_TRY_FMT requests. Given the fragile state of many
> > webcam firmwares, I wouldn't be surprised if some of them would simply
> > crash.
>
> Hmm, uvcvideo is sort of unique here in that TRY_FMT actually generates io
> (I know this is not something uvcvideo can help). What libv4l does, it
> finds out which formats the cam can support using ENUM_FMT (it does this
> only once), and then when a TRY_FMT is emulated by libv4l, and the app
> requested format is something libv4l can convert too, it will do a try_fmt
> with the app requested settings for all formats returned by enum_fmt to see
> using which format comes closes to what the app has requested. This is done
> because quite a few apps support different resolutions at different formats
> (including some uvc cams).
>
> If this really turns out to be a problem we need to look into this. Would
> using ENUM_FRAMESIZE for all formats once be better?

If the driver supports it, ENUM_FRAMESIZE is much better. This is exactly what 
is was designed for after all. TRY_FMT should then be used after the format 
and size has been selected from the enumerated list as the last step in 
format negotiation.

In this specific case I don't think the tsunami of TRY_FMT requests annoyed 
the camera, so there's no hurry. It could even be a good hardware stress 
test :-)

> > Then, and this might be the real issue here, the application calls
> > VIDIOC_S_FMT but libv4l doesn't relay that to the driver. I suppose
> > there's a check in the library that compares the requested format with
> > the current format and returns immediately if they are identical. This
> > means the camera doesn't receive any set format request between the two
> > runs. I wouldn't be surprised if camera developers never expected that.
>
> Correct, libv4l tries to cause as little IO as possible.

Regards,

Laurent Pinchart
_______________________________________________
Linux-uvc-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel

Reply via email to