--- 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.