From: Jean-Francois Moine <moinejf@free.fr>
To: Andrea <audetto@tiscali.it>
Cc: video4linux-list@redhat.com
Subject: Re: A question about VIDIOC_DQBUF
Date: Fri, 11 Jul 2008 09:31:52 +0200 [thread overview]
Message-ID: <1215761512.1679.17.camel@localhost> (raw)
In-Reply-To: <487678F6.50609@tiscali.it>
On Thu, 2008-07-10 at 22:02 +0100, Andrea wrote:
> Is there anybody who could help my with the followin?
Not sure, but I'll try.
> I would like to know if my interpretation of VIDIOC_DQBUF is correct.
[snip]
> >> - First, an application queues a buffer, then it dequeues the buffer.
> >> - Then again, a buffer is queued and then dequeued.
> >> - Dequeuing a buffer blocks is the buffer is not ready (unless device
> >> opened with O_NONBLOCK).
DQBUF blocks if _no_ buffer is ready.
> >> - Trying to dequeue a buffer without queuing it first is an error, and
> >> the ioctl VIDIOC_DQBUF should return -EINVAL.
You do not set a specific buffer at DQBUF call.
> > - One can only VIDIOC_DQBUF after calling STREAMON. Before it should
> > return -EINVAL? Block?
No, STREAMON may be done later by an other application.
> > - After calling STREAMOFF, VIDIOC_DQBUF should return -EINVAL
No, same reason as above.
> >> Now, about pwc: (if the above is correct).
> >>
> >> 1) VIDIOC_DQBUF blocks always until a buffer is ready, regardless of
> >> O_NONBLOCK.
Oh, bad guy!
> >> 2) VIDIOC_DQBUF does not check if a buffer has been previously queued.
> >> Moreover VIDIOC_QBUF is almost a no-op. It has no way to check if a
> >> buffer has been queued before VIDIOC_DQBUF.
Seems normal.
> >> If I have understood correctly (very unlikely), this is the reason why
> >> mplayer hangs while stopping the stream with pwc:
> >>
> >> while (!ioctl(priv->video_fd, VIDIOC_DQBUF, &buf));
> >>
> >
> > This code is not needed because STREAMOFF flushes the buffer queue. Does
> > it not?
Correct.
> >> This code should eventually return -EINVAL, while pwc just blocks
> >> waiting for the next buffer (which never arrives because
> >> VIDIOC_STREAMOFF has been called).
> >
> > pwc should return -EINVAL to all ioctl calls after STREAMOFF?
No.
> > Could someone please tell me where I am right and where I am wrong...
Done.
It was a good idea to point me on these problems. I will update the
gspca driver accordingly.
Thank you.
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
next prev parent reply other threads:[~2008-07-11 7:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-08 20:18 A question about VIDIOC_DQBUF Andrea
2008-07-08 22:14 ` Andrea
2008-07-10 21:02 ` Andrea
2008-07-11 7:31 ` Jean-Francois Moine [this message]
2008-07-11 20:03 ` Andrea
[not found] ` <c8b4dbe10807090704t4e98b8cu253fab39a9dd81d@mail.gmail.com>
2008-07-11 19:17 ` Andrea
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=1215761512.1679.17.camel@localhost \
--to=moinejf@free.fr \
--cc=audetto@tiscali.it \
--cc=video4linux-list@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.