--- zzzz-none-000/linux-3.10.107/Documentation/DocBook/media/v4l/func-poll.xml 2017-06-27 09:49:32.000000000 +0000
+++ scorpion-7490-727/linux-3.10.107/Documentation/DocBook/media/v4l/func-poll.xml 2021-02-04 17:41:59.000000000 +0000
@@ -29,9 +29,12 @@
to accept data for output.
When streaming I/O has been negotiated this function waits
-until a buffer has been filled or displayed and can be dequeued with
-the &VIDIOC-DQBUF; ioctl. When buffers are already in the outgoing
-queue of the driver the function returns immediately.
+until a buffer has been filled by the capture device and can be dequeued
+with the &VIDIOC-DQBUF; ioctl. For output devices this function waits
+until the device is ready to accept a new buffer to be queued up with
+the &VIDIOC-QBUF; ioctl for display. When buffers are already in the outgoing
+queue of the driver (capture) or the incoming queue isn't full (display)
+the function returns immediately.
On success poll() returns the number of
file descriptors that have been selected (that is, file descriptors
@@ -44,10 +47,22 @@
flags. When the function timed out it returns a value of zero, on
failure it returns -1 and the
errno variable is set appropriately. When the
-application did not call &VIDIOC-QBUF; or &VIDIOC-STREAMON; yet the
+application did not call &VIDIOC-STREAMON; the
poll() function succeeds, but sets the
POLLERR flag in the
-revents field.
+revents field. When the
+application has called &VIDIOC-STREAMON; for a capture device but hasn't
+yet called &VIDIOC-QBUF;, the poll() function
+succeeds and sets the POLLERR flag in the
+revents field. For output devices this
+same situation will cause poll() to succeed
+as well, but it sets the POLLOUT and
+POLLWRNORM flags in the revents
+field.
+
+ If an event occurred (see &VIDIOC-DQEVENT;) then
+POLLPRI will be set in the revents
+field and poll() will return.
When use of the read() function has
been negotiated and the driver does not capture yet, the
@@ -58,10 +73,18 @@
may return immediately.
When use of the write() function has
-been negotiated the poll function just waits
+been negotiated and the driver does not stream yet, the
+poll function starts streaming. When that fails
+it returns a POLLERR as above. Otherwise it waits
until the driver is ready for a non-blocking
write() call.
+ If the caller is only interested in events (just
+POLLPRI is set in the events
+field), then poll() will not
+start streaming if the driver does not stream yet. This makes it
+possible to just poll for events and not for buffers.
+
All drivers implementing the read() or
write() function or streaming I/O must also
support the poll() function.