xref: /OK3568_Linux_fs/kernel/Documentation/userspace-api/media/v4l/vidioc-qbuf.rst (revision 4882a59341e53eb6f0b4789bf948001014eff981)
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