1*4882a593Smuzhiyun.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later 2*4882a593Smuzhiyun.. c:namespace:: V4L 3*4882a593Smuzhiyun 4*4882a593Smuzhiyun.. _VIDIOC_QBUF: 5*4882a593Smuzhiyun 6*4882a593Smuzhiyun******************************* 7*4882a593Smuzhiyunioctl VIDIOC_QBUF, VIDIOC_DQBUF 8*4882a593Smuzhiyun******************************* 9*4882a593Smuzhiyun 10*4882a593SmuzhiyunName 11*4882a593Smuzhiyun==== 12*4882a593Smuzhiyun 13*4882a593SmuzhiyunVIDIOC_QBUF - VIDIOC_DQBUF - Exchange a buffer with the driver 14*4882a593Smuzhiyun 15*4882a593SmuzhiyunSynopsis 16*4882a593Smuzhiyun======== 17*4882a593Smuzhiyun 18*4882a593Smuzhiyun.. c:macro:: VIDIOC_QBUF 19*4882a593Smuzhiyun 20*4882a593Smuzhiyun``int ioctl(int fd, VIDIOC_QBUF, struct v4l2_buffer *argp)`` 21*4882a593Smuzhiyun 22*4882a593Smuzhiyun.. c:macro:: VIDIOC_DQBUF 23*4882a593Smuzhiyun 24*4882a593Smuzhiyun``int ioctl(int fd, VIDIOC_DQBUF, struct v4l2_buffer *argp)`` 25*4882a593Smuzhiyun 26*4882a593SmuzhiyunArguments 27*4882a593Smuzhiyun========= 28*4882a593Smuzhiyun 29*4882a593Smuzhiyun``fd`` 30*4882a593Smuzhiyun File descriptor returned by :c:func:`open()`. 31*4882a593Smuzhiyun 32*4882a593Smuzhiyun``argp`` 33*4882a593Smuzhiyun Pointer to struct :c:type:`v4l2_buffer`. 34*4882a593Smuzhiyun 35*4882a593SmuzhiyunDescription 36*4882a593Smuzhiyun=========== 37*4882a593Smuzhiyun 38*4882a593SmuzhiyunApplications call the ``VIDIOC_QBUF`` ioctl to enqueue an empty 39*4882a593Smuzhiyun(capturing) or filled (output) buffer in the driver's incoming queue. 40*4882a593SmuzhiyunThe semantics depend on the selected I/O method. 41*4882a593Smuzhiyun 42*4882a593SmuzhiyunTo enqueue a buffer applications set the ``type`` field of a struct 43*4882a593Smuzhiyun:c:type:`v4l2_buffer` to the same buffer type as was 44*4882a593Smuzhiyunpreviously used with struct :c:type:`v4l2_format` ``type`` 45*4882a593Smuzhiyunand struct :c:type:`v4l2_requestbuffers` ``type``. 46*4882a593SmuzhiyunApplications must also set the ``index`` field. Valid index numbers 47*4882a593Smuzhiyunrange from zero to the number of buffers allocated with 48*4882a593Smuzhiyun:ref:`VIDIOC_REQBUFS` (struct 49*4882a593Smuzhiyun:c:type:`v4l2_requestbuffers` ``count``) minus 50*4882a593Smuzhiyunone. The contents of the struct :c:type:`v4l2_buffer` returned 51*4882a593Smuzhiyunby a :ref:`VIDIOC_QUERYBUF` ioctl will do as well. 52*4882a593SmuzhiyunWhen the buffer is intended for output (``type`` is 53*4882a593Smuzhiyun``V4L2_BUF_TYPE_VIDEO_OUTPUT``, ``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE``, 54*4882a593Smuzhiyunor ``V4L2_BUF_TYPE_VBI_OUTPUT``) applications must also initialize the 55*4882a593Smuzhiyun``bytesused``, ``field`` and ``timestamp`` fields, see :ref:`buffer` 56*4882a593Smuzhiyunfor details. Applications must also set ``flags`` to 0. The 57*4882a593Smuzhiyun``reserved2`` and ``reserved`` fields must be set to 0. When using the 58*4882a593Smuzhiyun:ref:`multi-planar API <planar-apis>`, the ``m.planes`` field must 59*4882a593Smuzhiyuncontain a userspace pointer to a filled-in array of struct 60*4882a593Smuzhiyun:c:type:`v4l2_plane` and the ``length`` field must be set 61*4882a593Smuzhiyunto the number of elements in that array. 62*4882a593Smuzhiyun 63*4882a593SmuzhiyunTo enqueue a :ref:`memory mapped <mmap>` buffer applications set the 64*4882a593Smuzhiyun``memory`` field to ``V4L2_MEMORY_MMAP``. When ``VIDIOC_QBUF`` is called 65*4882a593Smuzhiyunwith a pointer to this structure the driver sets the 66*4882a593Smuzhiyun``V4L2_BUF_FLAG_MAPPED`` and ``V4L2_BUF_FLAG_QUEUED`` flags and clears 67*4882a593Smuzhiyunthe ``V4L2_BUF_FLAG_DONE`` flag in the ``flags`` field, or it returns an 68*4882a593Smuzhiyun``EINVAL`` error code. 69*4882a593Smuzhiyun 70*4882a593SmuzhiyunTo enqueue a :ref:`user pointer <userp>` buffer applications set the 71*4882a593Smuzhiyun``memory`` field to ``V4L2_MEMORY_USERPTR``, the ``m.userptr`` field to 72*4882a593Smuzhiyunthe address of the buffer and ``length`` to its size. When the 73*4882a593Smuzhiyunmulti-planar API is used, ``m.userptr`` and ``length`` members of the 74*4882a593Smuzhiyunpassed array of struct :c:type:`v4l2_plane` have to be used 75*4882a593Smuzhiyuninstead. When ``VIDIOC_QBUF`` is called with a pointer to this structure 76*4882a593Smuzhiyunthe driver sets the ``V4L2_BUF_FLAG_QUEUED`` flag and clears the 77*4882a593Smuzhiyun``V4L2_BUF_FLAG_MAPPED`` and ``V4L2_BUF_FLAG_DONE`` flags in the 78*4882a593Smuzhiyun``flags`` field, or it returns an error code. This ioctl locks the 79*4882a593Smuzhiyunmemory pages of the buffer in physical memory, they cannot be swapped 80*4882a593Smuzhiyunout to disk. Buffers remain locked until dequeued, until the 81*4882a593Smuzhiyun:ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` or 82*4882a593Smuzhiyun:ref:`VIDIOC_REQBUFS` ioctl is called, or until the 83*4882a593Smuzhiyundevice is closed. 84*4882a593Smuzhiyun 85*4882a593SmuzhiyunTo enqueue a :ref:`DMABUF <dmabuf>` buffer applications set the 86*4882a593Smuzhiyun``memory`` field to ``V4L2_MEMORY_DMABUF`` and the ``m.fd`` field to a 87*4882a593Smuzhiyunfile descriptor associated with a DMABUF buffer. When the multi-planar 88*4882a593SmuzhiyunAPI is used the ``m.fd`` fields of the passed array of struct 89*4882a593Smuzhiyun:c:type:`v4l2_plane` have to be used instead. When 90*4882a593Smuzhiyun``VIDIOC_QBUF`` is called with a pointer to this structure the driver 91*4882a593Smuzhiyunsets the ``V4L2_BUF_FLAG_QUEUED`` flag and clears the 92*4882a593Smuzhiyun``V4L2_BUF_FLAG_MAPPED`` and ``V4L2_BUF_FLAG_DONE`` flags in the 93*4882a593Smuzhiyun``flags`` field, or it returns an error code. This ioctl locks the 94*4882a593Smuzhiyunbuffer. Locking a buffer means passing it to a driver for a hardware 95*4882a593Smuzhiyunaccess (usually DMA). If an application accesses (reads/writes) a locked 96*4882a593Smuzhiyunbuffer then the result is undefined. Buffers remain locked until 97*4882a593Smuzhiyundequeued, until the :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` or 98*4882a593Smuzhiyun:ref:`VIDIOC_REQBUFS` ioctl is called, or until the 99*4882a593Smuzhiyundevice is closed. 100*4882a593Smuzhiyun 101*4882a593SmuzhiyunThe ``request_fd`` field can be used with the ``VIDIOC_QBUF`` ioctl to specify 102*4882a593Smuzhiyunthe file descriptor of a :ref:`request <media-request-api>`, if requests are 103*4882a593Smuzhiyunin use. Setting it means that the buffer will not be passed to the driver 104*4882a593Smuzhiyununtil the request itself is queued. Also, the driver will apply any 105*4882a593Smuzhiyunsettings associated with the request for this buffer. This field will 106*4882a593Smuzhiyunbe ignored unless the ``V4L2_BUF_FLAG_REQUEST_FD`` flag is set. 107*4882a593SmuzhiyunIf the device does not support requests, then ``EBADR`` will be returned. 108*4882a593SmuzhiyunIf requests are supported but an invalid request file descriptor is given, 109*4882a593Smuzhiyunthen ``EINVAL`` will be returned. 110*4882a593Smuzhiyun 111*4882a593Smuzhiyun.. caution:: 112*4882a593Smuzhiyun It is not allowed to mix queuing requests with queuing buffers directly. 113*4882a593Smuzhiyun ``EBUSY`` will be returned if the first buffer was queued directly and 114*4882a593Smuzhiyun then the application tries to queue a request, or vice versa. After 115*4882a593Smuzhiyun closing the file descriptor, calling 116*4882a593Smuzhiyun :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` or calling :ref:`VIDIOC_REQBUFS` 117*4882a593Smuzhiyun the check for this will be reset. 118*4882a593Smuzhiyun 119*4882a593Smuzhiyun For :ref:`memory-to-memory devices <mem2mem>` you can specify the 120*4882a593Smuzhiyun ``request_fd`` only for output buffers, not for capture buffers. Attempting 121*4882a593Smuzhiyun to specify this for a capture buffer will result in an ``EBADR`` error. 122*4882a593Smuzhiyun 123*4882a593SmuzhiyunApplications call the ``VIDIOC_DQBUF`` ioctl to dequeue a filled 124*4882a593Smuzhiyun(capturing) or displayed (output) buffer from the driver's outgoing 125*4882a593Smuzhiyunqueue. They just set the ``type``, ``memory`` and ``reserved`` fields of 126*4882a593Smuzhiyuna struct :c:type:`v4l2_buffer` as above, when 127*4882a593Smuzhiyun``VIDIOC_DQBUF`` is called with a pointer to this structure the driver 128*4882a593Smuzhiyunfills the remaining fields or returns an error code. The driver may also 129*4882a593Smuzhiyunset ``V4L2_BUF_FLAG_ERROR`` in the ``flags`` field. It indicates a 130*4882a593Smuzhiyunnon-critical (recoverable) streaming error. In such case the application 131*4882a593Smuzhiyunmay continue as normal, but should be aware that data in the dequeued 132*4882a593Smuzhiyunbuffer might be corrupted. When using the multi-planar API, the planes 133*4882a593Smuzhiyunarray must be passed in as well. 134*4882a593Smuzhiyun 135*4882a593SmuzhiyunIf the application sets the ``memory`` field to ``V4L2_MEMORY_DMABUF`` to 136*4882a593Smuzhiyundequeue a :ref:`DMABUF <dmabuf>` buffer, the driver fills the ``m.fd`` field 137*4882a593Smuzhiyunwith a file descriptor numerically the same as the one given to ``VIDIOC_QBUF`` 138*4882a593Smuzhiyunwhen the buffer was enqueued. No new file descriptor is created at dequeue time 139*4882a593Smuzhiyunand the value is only for the application convenience. When the multi-planar 140*4882a593SmuzhiyunAPI is used the ``m.fd`` fields of the passed array of struct 141*4882a593Smuzhiyun:c:type:`v4l2_plane` are filled instead. 142*4882a593Smuzhiyun 143*4882a593SmuzhiyunBy default ``VIDIOC_DQBUF`` blocks when no buffer is in the outgoing 144*4882a593Smuzhiyunqueue. When the ``O_NONBLOCK`` flag was given to the 145*4882a593Smuzhiyun:c:func:`open()` function, ``VIDIOC_DQBUF`` returns 146*4882a593Smuzhiyunimmediately with an ``EAGAIN`` error code when no buffer is available. 147*4882a593Smuzhiyun 148*4882a593SmuzhiyunThe struct :c:type:`v4l2_buffer` structure is specified in 149*4882a593Smuzhiyun:ref:`buffer`. 150*4882a593Smuzhiyun 151*4882a593SmuzhiyunReturn Value 152*4882a593Smuzhiyun============ 153*4882a593Smuzhiyun 154*4882a593SmuzhiyunOn success 0 is returned, on error -1 and the ``errno`` variable is set 155*4882a593Smuzhiyunappropriately. The generic error codes are described at the 156*4882a593Smuzhiyun:ref:`Generic Error Codes <gen-errors>` chapter. 157*4882a593Smuzhiyun 158*4882a593SmuzhiyunEAGAIN 159*4882a593Smuzhiyun Non-blocking I/O has been selected using ``O_NONBLOCK`` and no 160*4882a593Smuzhiyun buffer was in the outgoing queue. 161*4882a593Smuzhiyun 162*4882a593SmuzhiyunEINVAL 163*4882a593Smuzhiyun The buffer ``type`` is not supported, or the ``index`` is out of 164*4882a593Smuzhiyun bounds, or no buffers have been allocated yet, or the ``userptr`` or 165*4882a593Smuzhiyun ``length`` are invalid, or the ``V4L2_BUF_FLAG_REQUEST_FD`` flag was 166*4882a593Smuzhiyun set but the the given ``request_fd`` was invalid, or ``m.fd`` was 167*4882a593Smuzhiyun an invalid DMABUF file descriptor. 168*4882a593Smuzhiyun 169*4882a593SmuzhiyunEIO 170*4882a593Smuzhiyun ``VIDIOC_DQBUF`` failed due to an internal error. Can also indicate 171*4882a593Smuzhiyun temporary problems like signal loss. 172*4882a593Smuzhiyun 173*4882a593Smuzhiyun .. note:: 174*4882a593Smuzhiyun 175*4882a593Smuzhiyun The driver might dequeue an (empty) buffer despite returning 176*4882a593Smuzhiyun an error, or even stop capturing. Reusing such buffer may be unsafe 177*4882a593Smuzhiyun though and its details (e.g. ``index``) may not be returned either. 178*4882a593Smuzhiyun It is recommended that drivers indicate recoverable errors by setting 179*4882a593Smuzhiyun the ``V4L2_BUF_FLAG_ERROR`` and returning 0 instead. In that case the 180*4882a593Smuzhiyun application should be able to safely reuse the buffer and continue 181*4882a593Smuzhiyun streaming. 182*4882a593Smuzhiyun 183*4882a593SmuzhiyunEPIPE 184*4882a593Smuzhiyun ``VIDIOC_DQBUF`` returns this on an empty capture queue for mem2mem 185*4882a593Smuzhiyun codecs if a buffer with the ``V4L2_BUF_FLAG_LAST`` was already 186*4882a593Smuzhiyun dequeued and no new buffers are expected to become available. 187*4882a593Smuzhiyun 188*4882a593SmuzhiyunEBADR 189*4882a593Smuzhiyun The ``V4L2_BUF_FLAG_REQUEST_FD`` flag was set but the device does not 190*4882a593Smuzhiyun support requests for the given buffer type, or 191*4882a593Smuzhiyun the ``V4L2_BUF_FLAG_REQUEST_FD`` flag was not set but the device requires 192*4882a593Smuzhiyun that the buffer is part of a request. 193*4882a593Smuzhiyun 194*4882a593SmuzhiyunEBUSY 195*4882a593Smuzhiyun The first buffer was queued via a request, but the application now tries 196*4882a593Smuzhiyun to queue it directly, or vice versa (it is not permitted to mix the two 197*4882a593Smuzhiyun APIs). 198