Re: Regression at gspca core affecting SXGA mode on sn9c201 driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 12/07/2010 09:01 PM, Mauro Carvalho Chehab wrote:
Hi Jean-Fronçois,

git commit 35680baa6822df98a6ed602e2380aa0a04e18b07 (see enclosed) caused not only a regression
at PS/3 Eye webcam (git commit f43402fa55bf5e7e190c176343015122f694857c), but also at sn9c201 driver,
when used on SXGA mode. What happens is that only the highest alternate mode is enough for the
maximum resolution.

I suspect that other drivers broke due to that change. So, IMO, the better is to revert and work
on another alternative.


I have to agree with Mauro here, dropping back to a lower alt setting for all devices with a usb
audio interface is the wrong thing to do.

For example I know multiple devices where the highest alt setting does not have a wMaxPacketSize
of 1023, but use something lower instead, to make sure there is enough bandwidth left for usb audio
even if the highest alt setting get used.

Btw, no matter what resolution is used, sn9c201 is setting the same alternate for all modes,
spending more USB bandwidth than needed. Why gspca is just getting the highest value for
wMaxPacketSize? It should, instead, seek for the minimum packet size that is needed for a
given resolution.

There are 2 reasons for this:
1) We do not know the minimum packetsize for a given resolution, unlike with uvc where this
   is arranged in the protocol, for proprietary apps we can only guess
2) Almost all devices supported by gspca are usb-1.1 and thus the framerate is bandwidth
   limited. We want to deliver the highest framerate possible, and thus get as high an alt
   setting as possible.

I most note that many gspca subdrivers are defective wrt how this is all handled though, in
that they don't vary the framerate when the available bandwidth changes. So in many cases if
the gspca core cannot get the highest alt setting things may not function at all (because the
subdriver fails to select a lower framerate, resulting in parts of frames getting dropped
due to bandwidth limitations).

Fixing this requires:
1) Figuring out how to change the framerate for each sensor + bridge combo
2) Testing to see what framerate will still work at which alt setting

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux