Hans de Goede schrieb: > Hi, > > On 05/14/2010 08:00 AM, Jean-Francois Moine wrote: >> On Thu, 13 May 2010 17:58:49 +0200 >> Frank Schaefer<fschaefer.oss@xxxxxxxxxxxxxx> wrote: >> >>> I'm not sure if I'm hitting a bug or this is the expected driver >>> behavior: With a Microsoft LifeCam VX-3000 (045e:00f5) and >>> gspca-sonixj, ioctl VIDIOC_DQBUF intermittently blocks for exactly 3 >>> seconds and then returns EIO. >>> I noticed that it strongly depends on the captured scenery: when it's >>> changing much, everything is fine. >>> But when for example capturing the wall under constant (lower) light >>> conditions, I'm getting this error nearly permanently. >>> >>> It's a JPEG-device, so I guess the device stops sending data if the >>> picture doesn't change and that's how it should be. >>> But is the long blocking + EIO the way drivers should handle this >>> situtation ? >> >> Hello Frank, >> >> You are right, this is a bug. I did not know that a webcam could suspend >> streaming when the image did not change. I will remove the timeout. >> > > The way jpeg works mandates that for each block some data still needs to > be generated even if it is a solid color, moreover as these cams do jpeg > not mpeg, there is no delta towards the previous frame. So the cam should > not stop streaming if it doe timing out and returning -EIO is > appropriate. > > Thus we should not remove the DQBUF timeout IMHO. Urgh, sorry, of course jpeg is not mpeg ! So the device *should* not stop sending frames, which means that I will have to find out what's exactly going on in the kernel... Will need some time, I don't have permanent access to this device. Thanks so far, Frank -- 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
