Hi Carl, On Wednesday 15 June 2011 08:31:32 Carl Michal wrote: > On Tue, 14 Jun 2011, Alexey Fisher wrote: > > Am Montag, den 13.06.2011, 22:48 -0700 schrieb Carl Michal: > >>> Hi, > >>> > >>> I think you nailed it. Every frame looks perfect now. The trace shows > >>> a few of these: > >>> > >>> Jun 13 09:24:24 uvcvideo: Dropping payload (error bit set) > >>> > >>> but I don't see corrupt frames any more in either MJPG or YUYV (at > >>> 640x480 anyway) - in MJPG all the frames have the right size. > >>> > >>> There is a some weirdness with frame rates depending on the exposure > >>> setting: 1) Exposure, auto gives 4 options: auto priority mode, manual > >>> mode, shutter priority mode, and aperture priority mode. Auto and > >>> shutter don't seem to be settable (errors from guvcview when chosen). > >>> There is also an "Exposure, auto priority" checkbox. > >>> > >>> Frame rates drop dramatically in manual mode (to 10-15fps from 30). > >>> > >>> But I can't really complain at this point - the corrupt frames are > >>> gone. Will that quirk be added to the driver (usb id is: 0408:2fb1)? > >>> > >>> Thanks, > >> > >> Hi, > >> > >> it seems like I am much better off by fully disabling FID (with your > >> patch) than before. With the patch, YUYV frames are _always_ the right > >> size. There are still some problems: > >> > >> 1) corrupt frames - with part of the image missing or the image > >> displaced. Sometimes (but definitely not always) these occur at the > >> same time as a trace message saying the error bit is set. > >> > >> 2) sometimes the camera just won't start. when guvcview (or luvcview) > >> is started, no frames come back from the camera. There is a light next > >> to the camera that comes on to indicate it should be active, but no > >> frames arrive. There seems to be a fairly strong correlation with > >> using luvcview (which from the traces seems to use some different > >> mechanism to get frames from the driver from guvcview. guvcview polls, > >> luvcview doesn't). Sometimes just restarting guvcview several times > >> will work and the camera eventually starts. Sometimes just changing > >> resolution or frame rates succeeds in starting the camera. I haven't > >> found anything reproducible. I do not think this is related to your > >> patch, as it did happen once before your patch was applied. Unloading > >> and reloading the uvcvideo and ehci_hcd > >> > >> modules does not consistently solve it. guvcview just lists: > >> Could not grab image (select timeout): Resource temporarily > >> unavailable > >> > >> and the trace shows guvcview polling, but nothing else going on. > >> > >> I have tried adding the other quirks to the FID quirk, but haven't seen > >> any improvement with any others. > >> > >> Thanks for you help - > >> > >> Carl > > > > Webcam returns error in the middle of some frame, theoretically we > > should drop complete frame. But current uvcvideo just gather data and > > assume the cam will resend previous parts to complete the frame. > > > > Try attached patch additionally to my previous one. > > Hi, > > its very hard to say if this helps or not. There are still corrupt > frames, and some seem to occur at about the same time as the error bit > trace messages, but some don't show anything unusual in the traces that > I've noticed yet. > > Since all the uncompressed frames were the right size (even ones where the > error bit was set somewhere) those frames are at least complete.
Could you please add the packet size to the "Dropping payload (error bit set)" message ? I'm curious to see whether the error bit is set in empty packets only (len == data[0]) or in non-empty payloads as well. > Is there some convenient way to capture just those frames with the error > bit set? -- Regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
