vidioc-qbuf.rst 6.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154
  1. .. -*- coding: utf-8; mode: rst -*-
  2. .. _VIDIOC_QBUF:
  3. *******************************
  4. ioctl VIDIOC_QBUF, VIDIOC_DQBUF
  5. *******************************
  6. Name
  7. ====
  8. VIDIOC_QBUF - VIDIOC_DQBUF - Exchange a buffer with the driver
  9. Synopsis
  10. ========
  11. .. c:function:: int ioctl( int fd, VIDIOC_QBUF, struct v4l2_buffer *argp )
  12. :name: VIDIOC_QBUF
  13. .. c:function:: int ioctl( int fd, VIDIOC_DQBUF, struct v4l2_buffer *argp )
  14. :name: VIDIOC_DQBUF
  15. Arguments
  16. =========
  17. ``fd``
  18. File descriptor returned by :ref:`open() <func-open>`.
  19. ``argp``
  20. Description
  21. ===========
  22. Applications call the ``VIDIOC_QBUF`` ioctl to enqueue an empty
  23. (capturing) or filled (output) buffer in the driver's incoming queue.
  24. The semantics depend on the selected I/O method.
  25. To enqueue a buffer applications set the ``type`` field of a struct
  26. :c:type:`v4l2_buffer` to the same buffer type as was
  27. previously used with struct :c:type:`v4l2_format` ``type``
  28. and struct :c:type:`v4l2_requestbuffers` ``type``.
  29. Applications must also set the ``index`` field. Valid index numbers
  30. range from zero to the number of buffers allocated with
  31. :ref:`VIDIOC_REQBUFS` (struct
  32. :c:type:`v4l2_requestbuffers` ``count``) minus
  33. one. The contents of the struct :c:type:`v4l2_buffer` returned
  34. by a :ref:`VIDIOC_QUERYBUF` ioctl will do as well.
  35. When the buffer is intended for output (``type`` is
  36. ``V4L2_BUF_TYPE_VIDEO_OUTPUT``, ``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE``,
  37. or ``V4L2_BUF_TYPE_VBI_OUTPUT``) applications must also initialize the
  38. ``bytesused``, ``field`` and ``timestamp`` fields, see :ref:`buffer`
  39. for details. Applications must also set ``flags`` to 0. The
  40. ``reserved2`` and ``reserved`` fields must be set to 0. When using the
  41. :ref:`multi-planar API <planar-apis>`, the ``m.planes`` field must
  42. contain a userspace pointer to a filled-in array of struct
  43. :c:type:`v4l2_plane` and the ``length`` field must be set
  44. to the number of elements in that array.
  45. To enqueue a :ref:`memory mapped <mmap>` buffer applications set the
  46. ``memory`` field to ``V4L2_MEMORY_MMAP``. When ``VIDIOC_QBUF`` is called
  47. with a pointer to this structure the driver sets the
  48. ``V4L2_BUF_FLAG_MAPPED`` and ``V4L2_BUF_FLAG_QUEUED`` flags and clears
  49. the ``V4L2_BUF_FLAG_DONE`` flag in the ``flags`` field, or it returns an
  50. EINVAL error code.
  51. To enqueue a :ref:`user pointer <userp>` buffer applications set the
  52. ``memory`` field to ``V4L2_MEMORY_USERPTR``, the ``m.userptr`` field to
  53. the address of the buffer and ``length`` to its size. When the
  54. multi-planar API is used, ``m.userptr`` and ``length`` members of the
  55. passed array of struct :c:type:`v4l2_plane` have to be used
  56. instead. When ``VIDIOC_QBUF`` is called with a pointer to this structure
  57. the driver sets the ``V4L2_BUF_FLAG_QUEUED`` flag and clears the
  58. ``V4L2_BUF_FLAG_MAPPED`` and ``V4L2_BUF_FLAG_DONE`` flags in the
  59. ``flags`` field, or it returns an error code. This ioctl locks the
  60. memory pages of the buffer in physical memory, they cannot be swapped
  61. out to disk. Buffers remain locked until dequeued, until the
  62. :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` or
  63. :ref:`VIDIOC_REQBUFS` ioctl is called, or until the
  64. device is closed.
  65. To enqueue a :ref:`DMABUF <dmabuf>` buffer applications set the
  66. ``memory`` field to ``V4L2_MEMORY_DMABUF`` and the ``m.fd`` field to a
  67. file descriptor associated with a DMABUF buffer. When the multi-planar
  68. API is used the ``m.fd`` fields of the passed array of struct
  69. :c:type:`v4l2_plane` have to be used instead. When
  70. ``VIDIOC_QBUF`` is called with a pointer to this structure the driver
  71. sets the ``V4L2_BUF_FLAG_QUEUED`` flag and clears the
  72. ``V4L2_BUF_FLAG_MAPPED`` and ``V4L2_BUF_FLAG_DONE`` flags in the
  73. ``flags`` field, or it returns an error code. This ioctl locks the
  74. buffer. Locking a buffer means passing it to a driver for a hardware
  75. access (usually DMA). If an application accesses (reads/writes) a locked
  76. buffer then the result is undefined. Buffers remain locked until
  77. dequeued, until the :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` or
  78. :ref:`VIDIOC_REQBUFS` ioctl is called, or until the
  79. device is closed.
  80. Applications call the ``VIDIOC_DQBUF`` ioctl to dequeue a filled
  81. (capturing) or displayed (output) buffer from the driver's outgoing
  82. queue. They just set the ``type``, ``memory`` and ``reserved`` fields of
  83. a struct :c:type:`v4l2_buffer` as above, when
  84. ``VIDIOC_DQBUF`` is called with a pointer to this structure the driver
  85. fills the remaining fields or returns an error code. The driver may also
  86. set ``V4L2_BUF_FLAG_ERROR`` in the ``flags`` field. It indicates a
  87. non-critical (recoverable) streaming error. In such case the application
  88. may continue as normal, but should be aware that data in the dequeued
  89. buffer might be corrupted. When using the multi-planar API, the planes
  90. array must be passed in as well.
  91. By default ``VIDIOC_DQBUF`` blocks when no buffer is in the outgoing
  92. queue. When the ``O_NONBLOCK`` flag was given to the
  93. :ref:`open() <func-open>` function, ``VIDIOC_DQBUF`` returns
  94. immediately with an ``EAGAIN`` error code when no buffer is available.
  95. The struct :c:type:`v4l2_buffer` structure is specified in
  96. :ref:`buffer`.
  97. Return Value
  98. ============
  99. On success 0 is returned, on error -1 and the ``errno`` variable is set
  100. appropriately. The generic error codes are described at the
  101. :ref:`Generic Error Codes <gen-errors>` chapter.
  102. EAGAIN
  103. Non-blocking I/O has been selected using ``O_NONBLOCK`` and no
  104. buffer was in the outgoing queue.
  105. EINVAL
  106. The buffer ``type`` is not supported, or the ``index`` is out of
  107. bounds, or no buffers have been allocated yet, or the ``userptr`` or
  108. ``length`` are invalid.
  109. EIO
  110. ``VIDIOC_DQBUF`` failed due to an internal error. Can also indicate
  111. temporary problems like signal loss.
  112. .. note::
  113. The driver might dequeue an (empty) buffer despite returning
  114. an error, or even stop capturing. Reusing such buffer may be unsafe
  115. though and its details (e.g. ``index``) may not be returned either.
  116. It is recommended that drivers indicate recoverable errors by setting
  117. the ``V4L2_BUF_FLAG_ERROR`` and returning 0 instead. In that case the
  118. application should be able to safely reuse the buffer and continue
  119. streaming.
  120. EPIPE
  121. ``VIDIOC_DQBUF`` returns this on an empty capture queue for mem2mem
  122. codecs if a buffer with the ``V4L2_BUF_FLAG_LAST`` was already
  123. dequeued and no new buffers are expected to become available.