18c2ecf20Sopenharmony_ci.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later 28c2ecf20Sopenharmony_ci.. c:namespace:: V4L 38c2ecf20Sopenharmony_ci 48c2ecf20Sopenharmony_ci.. _VIDIOC_QBUF: 58c2ecf20Sopenharmony_ci 68c2ecf20Sopenharmony_ci******************************* 78c2ecf20Sopenharmony_ciioctl VIDIOC_QBUF, VIDIOC_DQBUF 88c2ecf20Sopenharmony_ci******************************* 98c2ecf20Sopenharmony_ci 108c2ecf20Sopenharmony_ciName 118c2ecf20Sopenharmony_ci==== 128c2ecf20Sopenharmony_ci 138c2ecf20Sopenharmony_ciVIDIOC_QBUF - VIDIOC_DQBUF - Exchange a buffer with the driver 148c2ecf20Sopenharmony_ci 158c2ecf20Sopenharmony_ciSynopsis 168c2ecf20Sopenharmony_ci======== 178c2ecf20Sopenharmony_ci 188c2ecf20Sopenharmony_ci.. c:macro:: VIDIOC_QBUF 198c2ecf20Sopenharmony_ci 208c2ecf20Sopenharmony_ci``int ioctl(int fd, VIDIOC_QBUF, struct v4l2_buffer *argp)`` 218c2ecf20Sopenharmony_ci 228c2ecf20Sopenharmony_ci.. c:macro:: VIDIOC_DQBUF 238c2ecf20Sopenharmony_ci 248c2ecf20Sopenharmony_ci``int ioctl(int fd, VIDIOC_DQBUF, struct v4l2_buffer *argp)`` 258c2ecf20Sopenharmony_ci 268c2ecf20Sopenharmony_ciArguments 278c2ecf20Sopenharmony_ci========= 288c2ecf20Sopenharmony_ci 298c2ecf20Sopenharmony_ci``fd`` 308c2ecf20Sopenharmony_ci File descriptor returned by :c:func:`open()`. 318c2ecf20Sopenharmony_ci 328c2ecf20Sopenharmony_ci``argp`` 338c2ecf20Sopenharmony_ci Pointer to struct :c:type:`v4l2_buffer`. 348c2ecf20Sopenharmony_ci 358c2ecf20Sopenharmony_ciDescription 368c2ecf20Sopenharmony_ci=========== 378c2ecf20Sopenharmony_ci 388c2ecf20Sopenharmony_ciApplications call the ``VIDIOC_QBUF`` ioctl to enqueue an empty 398c2ecf20Sopenharmony_ci(capturing) or filled (output) buffer in the driver's incoming queue. 408c2ecf20Sopenharmony_ciThe semantics depend on the selected I/O method. 418c2ecf20Sopenharmony_ci 428c2ecf20Sopenharmony_ciTo enqueue a buffer applications set the ``type`` field of a struct 438c2ecf20Sopenharmony_ci:c:type:`v4l2_buffer` to the same buffer type as was 448c2ecf20Sopenharmony_cipreviously used with struct :c:type:`v4l2_format` ``type`` 458c2ecf20Sopenharmony_ciand struct :c:type:`v4l2_requestbuffers` ``type``. 468c2ecf20Sopenharmony_ciApplications must also set the ``index`` field. Valid index numbers 478c2ecf20Sopenharmony_cirange from zero to the number of buffers allocated with 488c2ecf20Sopenharmony_ci:ref:`VIDIOC_REQBUFS` (struct 498c2ecf20Sopenharmony_ci:c:type:`v4l2_requestbuffers` ``count``) minus 508c2ecf20Sopenharmony_cione. The contents of the struct :c:type:`v4l2_buffer` returned 518c2ecf20Sopenharmony_ciby a :ref:`VIDIOC_QUERYBUF` ioctl will do as well. 528c2ecf20Sopenharmony_ciWhen the buffer is intended for output (``type`` is 538c2ecf20Sopenharmony_ci``V4L2_BUF_TYPE_VIDEO_OUTPUT``, ``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE``, 548c2ecf20Sopenharmony_cior ``V4L2_BUF_TYPE_VBI_OUTPUT``) applications must also initialize the 558c2ecf20Sopenharmony_ci``bytesused``, ``field`` and ``timestamp`` fields, see :ref:`buffer` 568c2ecf20Sopenharmony_cifor details. Applications must also set ``flags`` to 0. The 578c2ecf20Sopenharmony_ci``reserved2`` and ``reserved`` fields must be set to 0. When using the 588c2ecf20Sopenharmony_ci:ref:`multi-planar API <planar-apis>`, the ``m.planes`` field must 598c2ecf20Sopenharmony_cicontain a userspace pointer to a filled-in array of struct 608c2ecf20Sopenharmony_ci:c:type:`v4l2_plane` and the ``length`` field must be set 618c2ecf20Sopenharmony_cito the number of elements in that array. 628c2ecf20Sopenharmony_ci 638c2ecf20Sopenharmony_ciTo enqueue a :ref:`memory mapped <mmap>` buffer applications set the 648c2ecf20Sopenharmony_ci``memory`` field to ``V4L2_MEMORY_MMAP``. When ``VIDIOC_QBUF`` is called 658c2ecf20Sopenharmony_ciwith a pointer to this structure the driver sets the 668c2ecf20Sopenharmony_ci``V4L2_BUF_FLAG_MAPPED`` and ``V4L2_BUF_FLAG_QUEUED`` flags and clears 678c2ecf20Sopenharmony_cithe ``V4L2_BUF_FLAG_DONE`` flag in the ``flags`` field, or it returns an 688c2ecf20Sopenharmony_ci``EINVAL`` error code. 698c2ecf20Sopenharmony_ci 708c2ecf20Sopenharmony_ciTo enqueue a :ref:`user pointer <userp>` buffer applications set the 718c2ecf20Sopenharmony_ci``memory`` field to ``V4L2_MEMORY_USERPTR``, the ``m.userptr`` field to 728c2ecf20Sopenharmony_cithe address of the buffer and ``length`` to its size. When the 738c2ecf20Sopenharmony_cimulti-planar API is used, ``m.userptr`` and ``length`` members of the 748c2ecf20Sopenharmony_cipassed array of struct :c:type:`v4l2_plane` have to be used 758c2ecf20Sopenharmony_ciinstead. When ``VIDIOC_QBUF`` is called with a pointer to this structure 768c2ecf20Sopenharmony_cithe driver sets the ``V4L2_BUF_FLAG_QUEUED`` flag and clears the 778c2ecf20Sopenharmony_ci``V4L2_BUF_FLAG_MAPPED`` and ``V4L2_BUF_FLAG_DONE`` flags in the 788c2ecf20Sopenharmony_ci``flags`` field, or it returns an error code. This ioctl locks the 798c2ecf20Sopenharmony_cimemory pages of the buffer in physical memory, they cannot be swapped 808c2ecf20Sopenharmony_ciout to disk. Buffers remain locked until dequeued, until the 818c2ecf20Sopenharmony_ci:ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` or 828c2ecf20Sopenharmony_ci:ref:`VIDIOC_REQBUFS` ioctl is called, or until the 838c2ecf20Sopenharmony_cidevice is closed. 848c2ecf20Sopenharmony_ci 858c2ecf20Sopenharmony_ciTo enqueue a :ref:`DMABUF <dmabuf>` buffer applications set the 868c2ecf20Sopenharmony_ci``memory`` field to ``V4L2_MEMORY_DMABUF`` and the ``m.fd`` field to a 878c2ecf20Sopenharmony_cifile descriptor associated with a DMABUF buffer. When the multi-planar 888c2ecf20Sopenharmony_ciAPI is used the ``m.fd`` fields of the passed array of struct 898c2ecf20Sopenharmony_ci:c:type:`v4l2_plane` have to be used instead. When 908c2ecf20Sopenharmony_ci``VIDIOC_QBUF`` is called with a pointer to this structure the driver 918c2ecf20Sopenharmony_cisets the ``V4L2_BUF_FLAG_QUEUED`` flag and clears the 928c2ecf20Sopenharmony_ci``V4L2_BUF_FLAG_MAPPED`` and ``V4L2_BUF_FLAG_DONE`` flags in the 938c2ecf20Sopenharmony_ci``flags`` field, or it returns an error code. This ioctl locks the 948c2ecf20Sopenharmony_cibuffer. Locking a buffer means passing it to a driver for a hardware 958c2ecf20Sopenharmony_ciaccess (usually DMA). If an application accesses (reads/writes) a locked 968c2ecf20Sopenharmony_cibuffer then the result is undefined. Buffers remain locked until 978c2ecf20Sopenharmony_cidequeued, until the :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` or 988c2ecf20Sopenharmony_ci:ref:`VIDIOC_REQBUFS` ioctl is called, or until the 998c2ecf20Sopenharmony_cidevice is closed. 1008c2ecf20Sopenharmony_ci 1018c2ecf20Sopenharmony_ciThe ``request_fd`` field can be used with the ``VIDIOC_QBUF`` ioctl to specify 1028c2ecf20Sopenharmony_cithe file descriptor of a :ref:`request <media-request-api>`, if requests are 1038c2ecf20Sopenharmony_ciin use. Setting it means that the buffer will not be passed to the driver 1048c2ecf20Sopenharmony_ciuntil the request itself is queued. Also, the driver will apply any 1058c2ecf20Sopenharmony_cisettings associated with the request for this buffer. This field will 1068c2ecf20Sopenharmony_cibe ignored unless the ``V4L2_BUF_FLAG_REQUEST_FD`` flag is set. 1078c2ecf20Sopenharmony_ciIf the device does not support requests, then ``EBADR`` will be returned. 1088c2ecf20Sopenharmony_ciIf requests are supported but an invalid request file descriptor is given, 1098c2ecf20Sopenharmony_cithen ``EINVAL`` will be returned. 1108c2ecf20Sopenharmony_ci 1118c2ecf20Sopenharmony_ci.. caution:: 1128c2ecf20Sopenharmony_ci It is not allowed to mix queuing requests with queuing buffers directly. 1138c2ecf20Sopenharmony_ci ``EBUSY`` will be returned if the first buffer was queued directly and 1148c2ecf20Sopenharmony_ci then the application tries to queue a request, or vice versa. After 1158c2ecf20Sopenharmony_ci closing the file descriptor, calling 1168c2ecf20Sopenharmony_ci :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` or calling :ref:`VIDIOC_REQBUFS` 1178c2ecf20Sopenharmony_ci the check for this will be reset. 1188c2ecf20Sopenharmony_ci 1198c2ecf20Sopenharmony_ci For :ref:`memory-to-memory devices <mem2mem>` you can specify the 1208c2ecf20Sopenharmony_ci ``request_fd`` only for output buffers, not for capture buffers. Attempting 1218c2ecf20Sopenharmony_ci to specify this for a capture buffer will result in an ``EBADR`` error. 1228c2ecf20Sopenharmony_ci 1238c2ecf20Sopenharmony_ciApplications call the ``VIDIOC_DQBUF`` ioctl to dequeue a filled 1248c2ecf20Sopenharmony_ci(capturing) or displayed (output) buffer from the driver's outgoing 1258c2ecf20Sopenharmony_ciqueue. They just set the ``type``, ``memory`` and ``reserved`` fields of 1268c2ecf20Sopenharmony_cia struct :c:type:`v4l2_buffer` as above, when 1278c2ecf20Sopenharmony_ci``VIDIOC_DQBUF`` is called with a pointer to this structure the driver 1288c2ecf20Sopenharmony_cifills the remaining fields or returns an error code. The driver may also 1298c2ecf20Sopenharmony_ciset ``V4L2_BUF_FLAG_ERROR`` in the ``flags`` field. It indicates a 1308c2ecf20Sopenharmony_cinon-critical (recoverable) streaming error. In such case the application 1318c2ecf20Sopenharmony_cimay continue as normal, but should be aware that data in the dequeued 1328c2ecf20Sopenharmony_cibuffer might be corrupted. When using the multi-planar API, the planes 1338c2ecf20Sopenharmony_ciarray must be passed in as well. 1348c2ecf20Sopenharmony_ci 1358c2ecf20Sopenharmony_ciIf the application sets the ``memory`` field to ``V4L2_MEMORY_DMABUF`` to 1368c2ecf20Sopenharmony_cidequeue a :ref:`DMABUF <dmabuf>` buffer, the driver fills the ``m.fd`` field 1378c2ecf20Sopenharmony_ciwith a file descriptor numerically the same as the one given to ``VIDIOC_QBUF`` 1388c2ecf20Sopenharmony_ciwhen the buffer was enqueued. No new file descriptor is created at dequeue time 1398c2ecf20Sopenharmony_ciand the value is only for the application convenience. When the multi-planar 1408c2ecf20Sopenharmony_ciAPI is used the ``m.fd`` fields of the passed array of struct 1418c2ecf20Sopenharmony_ci:c:type:`v4l2_plane` are filled instead. 1428c2ecf20Sopenharmony_ci 1438c2ecf20Sopenharmony_ciBy default ``VIDIOC_DQBUF`` blocks when no buffer is in the outgoing 1448c2ecf20Sopenharmony_ciqueue. When the ``O_NONBLOCK`` flag was given to the 1458c2ecf20Sopenharmony_ci:c:func:`open()` function, ``VIDIOC_DQBUF`` returns 1468c2ecf20Sopenharmony_ciimmediately with an ``EAGAIN`` error code when no buffer is available. 1478c2ecf20Sopenharmony_ci 1488c2ecf20Sopenharmony_ciThe struct :c:type:`v4l2_buffer` structure is specified in 1498c2ecf20Sopenharmony_ci:ref:`buffer`. 1508c2ecf20Sopenharmony_ci 1518c2ecf20Sopenharmony_ciReturn Value 1528c2ecf20Sopenharmony_ci============ 1538c2ecf20Sopenharmony_ci 1548c2ecf20Sopenharmony_ciOn success 0 is returned, on error -1 and the ``errno`` variable is set 1558c2ecf20Sopenharmony_ciappropriately. The generic error codes are described at the 1568c2ecf20Sopenharmony_ci:ref:`Generic Error Codes <gen-errors>` chapter. 1578c2ecf20Sopenharmony_ci 1588c2ecf20Sopenharmony_ciEAGAIN 1598c2ecf20Sopenharmony_ci Non-blocking I/O has been selected using ``O_NONBLOCK`` and no 1608c2ecf20Sopenharmony_ci buffer was in the outgoing queue. 1618c2ecf20Sopenharmony_ci 1628c2ecf20Sopenharmony_ciEINVAL 1638c2ecf20Sopenharmony_ci The buffer ``type`` is not supported, or the ``index`` is out of 1648c2ecf20Sopenharmony_ci bounds, or no buffers have been allocated yet, or the ``userptr`` or 1658c2ecf20Sopenharmony_ci ``length`` are invalid, or the ``V4L2_BUF_FLAG_REQUEST_FD`` flag was 1668c2ecf20Sopenharmony_ci set but the the given ``request_fd`` was invalid, or ``m.fd`` was 1678c2ecf20Sopenharmony_ci an invalid DMABUF file descriptor. 1688c2ecf20Sopenharmony_ci 1698c2ecf20Sopenharmony_ciEIO 1708c2ecf20Sopenharmony_ci ``VIDIOC_DQBUF`` failed due to an internal error. Can also indicate 1718c2ecf20Sopenharmony_ci temporary problems like signal loss. 1728c2ecf20Sopenharmony_ci 1738c2ecf20Sopenharmony_ci .. note:: 1748c2ecf20Sopenharmony_ci 1758c2ecf20Sopenharmony_ci The driver might dequeue an (empty) buffer despite returning 1768c2ecf20Sopenharmony_ci an error, or even stop capturing. Reusing such buffer may be unsafe 1778c2ecf20Sopenharmony_ci though and its details (e.g. ``index``) may not be returned either. 1788c2ecf20Sopenharmony_ci It is recommended that drivers indicate recoverable errors by setting 1798c2ecf20Sopenharmony_ci the ``V4L2_BUF_FLAG_ERROR`` and returning 0 instead. In that case the 1808c2ecf20Sopenharmony_ci application should be able to safely reuse the buffer and continue 1818c2ecf20Sopenharmony_ci streaming. 1828c2ecf20Sopenharmony_ci 1838c2ecf20Sopenharmony_ciEPIPE 1848c2ecf20Sopenharmony_ci ``VIDIOC_DQBUF`` returns this on an empty capture queue for mem2mem 1858c2ecf20Sopenharmony_ci codecs if a buffer with the ``V4L2_BUF_FLAG_LAST`` was already 1868c2ecf20Sopenharmony_ci dequeued and no new buffers are expected to become available. 1878c2ecf20Sopenharmony_ci 1888c2ecf20Sopenharmony_ciEBADR 1898c2ecf20Sopenharmony_ci The ``V4L2_BUF_FLAG_REQUEST_FD`` flag was set but the device does not 1908c2ecf20Sopenharmony_ci support requests for the given buffer type, or 1918c2ecf20Sopenharmony_ci the ``V4L2_BUF_FLAG_REQUEST_FD`` flag was not set but the device requires 1928c2ecf20Sopenharmony_ci that the buffer is part of a request. 1938c2ecf20Sopenharmony_ci 1948c2ecf20Sopenharmony_ciEBUSY 1958c2ecf20Sopenharmony_ci The first buffer was queued via a request, but the application now tries 1968c2ecf20Sopenharmony_ci to queue it directly, or vice versa (it is not permitted to mix the two 1978c2ecf20Sopenharmony_ci APIs). 198