[pwc] About streaming in pwc with v4l2

[Andrea]

Hi,

I've been writing a few mails about the implementation of the streaming functions in pwc.
I am talking about the ioctls

VIDIOC_DQBUF
VIDIOC_QBUF
VIDIOC_STREAMON
VIDIOC_STREAMOFF

I think those are related to the fact that mplayer hangs at the end of a video played from pwc with 
v4l2.

I have not received any feedback so far, so I might say something not exact. Please correct me.

Usually an application should queue all buffers (QBUF) and then in a loop dequeue a buffer (DQBUF), 
use it, and requeue it.

A driver should only dequeue buffers that have been queued.

When STREAMOFF is called all queued buffer should be destroyed, and following calls to DQBUF should 
fail.

As a source of that I've read

http://lwn.net/Articles/240667/
http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec/r8849.htm
and the example code
capture-example.c at linuxtv mercurial under v4l2-apps/test/capture-example.c

I think the implementation of those function in pwc has the following issues

1) it does not keep track of which buffers have been queued and behave as they are always queued and 
available to the driver
2) STREAMOFF does not destroy any buffer (since there is no list of them)
3) after STREAMOFF, since the list should be empty, DQBUF should return -EINVAL. pwc does not know 
about that and waits forever.
4) DQBUF should not block if a buffer is not ready and the device has been opened with O_NONBLOCK.

The hangs is due to the fact that mplayer calls
1) STREAMOFF
2) DQBUF in a loop (this should return -EINVAL, but pwc never returns, since it is waiting for a 
buffer that never arrives (STREAMOFF stops the reception from the camera))

I think mplayer could get rid of the redundant calls to DQBUF after STREAMOFF, but I don't think it 
qualifies as a bug.

I would like to have a second opinion about that before changing those functions in pwc.

Cheers

Andrea