Hans Verkuil schreef:
On Sunday 04 February 2007 15:23, Michel Verbraak wrote:
Hans Verkuil schreef:
On Sunday 04 February 2007 13:43, Michel Verbraak wrote:
I was debugging a small program of mine and found that:
- when I do a poll after opening the device, and not doing a read
first, it would always give me a POLLERR instead of a POLLIN.
Example:
videofd=open("/dev/video0", O_RDONLY);
// Add video device
poll_item.fd = videofd;
poll_item.events = POLLIN;
poll_item.revents = 0;
// poll infinite
retvalue = poll(&poll_item, 1, -1);
poll_item.revents is allways POLLERR.
When I do a read(videofd, buffer, 0); directly after the open and
then do the poll I get POLLIN.
I can trace this back to the fact that the bit IVTV_F_S_STREAMING
is only set, in function ivtv_v4l2_read in file ivtv-fileops.c,
when at least one read is done. Even if the request is to read 0
(zero) bytes.
I do not know if this is by design.
But I would think that it should be possible to first do a poll to
see if data is available to read before I even do any reading. So
probably the IVTV_F_S_STREAMING bit should be set in the function
ivtv_v4l2_open in file ivtv-fileops.c.
This problem is in ivtv 0.10.0RC1 and I would think even in the
earlier versions.
I did not yet spend time to find a fix because I would first like
to know if this is by design or not.
It's by design, but I'm not certain whether it is the right design.
Basically just opening the device will not start a capture, it has
to be started explicitly, either by a read or by an IVTV_IOC_PLAY
ioctl. It is unclear what poll should do if no capture is in
progress. Wait indefinitely? Automatically start a capture? Or
return an error? I can't find a clear answer in the V4L2 spec.
I'll ask on the video4linux mailinglist, see what the correct
policy is.
Thanks,
Hans
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
The program I'm writing does not known it is reading from an ivtv
device. The file handle could be a device or a file or a socket.
I would like to keep it this way because otherwise I have to make two
different programs or during startup I have to specify if it is an
ivtv device or the other. During startup I only specify te location
like /dev/video0 or /movies/somemovie.avi or 192.168.1.1:10000 and
the program either opens the device or file or creates a tcp socket.
And some other program or thread will actually start the capture? Just
opening a v4l2 device will NEVER automatically start a capture.
Otherwise even opening a video device just to change the frequency
would have the nasty side-effect of beginning a capture.
Regards,
Hans
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
I currently have another program which does the channel changing.
But would it not be better that the driver, even not capturing, on a
poll request with poll_item.events = POLLIN it should check if it is
able to start a capture so reading can start and on the first next read
will really start the capture. If it is not able to start capturing on a
first read then return POLLERR otherwise return POLLIN.
In this way when the driver is not capturing and a poll would return
POLLIN my program can start reading. Sockets act this way.
Currently my program just reads zero bytes before doing the poll and
this works. And it will also work on a normal file.
To explain my program: It is a small server. When a client connects it
opens the device/file/socket and reads data from it. It copies the data
unchanged to the client. If a second or third, etc.., client connects
the read data is copied unchanged to all the clients. When the last
client disconnects it closes the device/file/socket. The other program
only changes the channels on request of a client.
For the server and client sockets in my programs I use poll to check if
something needs to be communicated. In this I would like to put the file
descriptor of the device so it only reads if the device is able to
deliver data.
Regards,
Michel.
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
