linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Jean-Francois Moine <moinejf@free.fr>
Cc: Frank Schaefer <fschaefer.oss@googlemail.com>,
	linux-media@vger.kernel.org
Subject: Re: gspca-sonixj: ioctl VIDIOC_DQBUF blocks for 3s and retuns EIO
Date: Fri, 14 May 2010 09:26:15 +0200	[thread overview]
Message-ID: <4BECFB17.1040500@redhat.com> (raw)
In-Reply-To: <20100514080049.1cf7c726@tele>

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@googlemail.com>  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.

Regards,

Hans

  reply	other threads:[~2010-05-14  7:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-13 15:58 gspca-sonixj: ioctl VIDIOC_DQBUF blocks for 3s and retuns EIO Frank Schaefer
2010-05-14  6:00 ` Jean-Francois Moine
2010-05-14  7:26   ` Hans de Goede [this message]
2010-05-14 18:44     ` Frank Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BECFB17.1040500@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=fschaefer.oss@googlemail.com \
    --cc=linux-media@vger.kernel.org \
    --cc=moinejf@free.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).