1.. Permission is granted to copy, distribute and/or modify this 2.. document under the terms of the GNU Free Documentation License, 3.. Version 1.1 or any later version published by the Free Software 4.. Foundation, with no Invariant Sections, no Front-Cover Texts 5.. and no Back-Cover Texts. A copy of the license is included at 6.. Documentation/userspace-api/media/fdl-appendix.rst. 7.. 8.. TODO: replace it to GFDL-1.1-or-later WITH no-invariant-sections 9 10.. _func-mmap: 11 12*********** 13V4L2 mmap() 14*********** 15 16Name 17==== 18 19v4l2-mmap - Map device memory into application address space 20 21 22Synopsis 23======== 24 25.. code-block:: c 26 27 #include <unistd.h> 28 #include <sys/mman.h> 29 30 31.. c:function:: void *mmap( void *start, size_t length, int prot, int flags, int fd, off_t offset ) 32 :name: v4l2-mmap 33 34Arguments 35========= 36 37``start`` 38 Map the buffer to this address in the application's address space. 39 When the ``MAP_FIXED`` flag is specified, ``start`` must be a 40 multiple of the pagesize and mmap will fail when the specified 41 address cannot be used. Use of this option is discouraged; 42 applications should just specify a ``NULL`` pointer here. 43 44``length`` 45 Length of the memory area to map. This must be the same value as 46 returned by the driver in the struct 47 :c:type:`v4l2_buffer` ``length`` field for the 48 single-planar API, and the same value as returned by the driver in 49 the struct :c:type:`v4l2_plane` ``length`` field for 50 the multi-planar API. 51 52``prot`` 53 The ``prot`` argument describes the desired memory protection. 54 Regardless of the device type and the direction of data exchange it 55 should be set to ``PROT_READ`` | ``PROT_WRITE``, permitting read 56 and write access to image buffers. Drivers should support at least 57 this combination of flags. 58 59 .. note:: 60 61 #. The Linux ``videobuf`` kernel module, which is used by some 62 drivers supports only ``PROT_READ`` | ``PROT_WRITE``. When the 63 driver does not support the desired protection, the 64 :ref:`mmap() <func-mmap>` function fails. 65 66 #. Device memory accesses (e. g. the memory on a graphics card 67 with video capturing hardware) may incur a performance penalty 68 compared to main memory accesses, or reads may be significantly 69 slower than writes or vice versa. Other I/O methods may be more 70 efficient in such case. 71 72``flags`` 73 The ``flags`` parameter specifies the type of the mapped object, 74 mapping options and whether modifications made to the mapped copy of 75 the page are private to the process or are to be shared with other 76 references. 77 78 ``MAP_FIXED`` requests that the driver selects no other address than 79 the one specified. If the specified address cannot be used, 80 :ref:`mmap() <func-mmap>` will fail. If ``MAP_FIXED`` is specified, 81 ``start`` must be a multiple of the pagesize. Use of this option is 82 discouraged. 83 84 One of the ``MAP_SHARED`` or ``MAP_PRIVATE`` flags must be set. 85 ``MAP_SHARED`` allows applications to share the mapped memory with 86 other (e. g. child-) processes. 87 88 .. note:: 89 90 The Linux ``videobuf`` module which is used by some 91 drivers supports only ``MAP_SHARED``. ``MAP_PRIVATE`` requests 92 copy-on-write semantics. V4L2 applications should not set the 93 ``MAP_PRIVATE``, ``MAP_DENYWRITE``, ``MAP_EXECUTABLE`` or ``MAP_ANON`` 94 flags. 95 96``fd`` 97 File descriptor returned by :ref:`open() <func-open>`. 98 99``offset`` 100 Offset of the buffer in device memory. This must be the same value 101 as returned by the driver in the struct 102 :c:type:`v4l2_buffer` ``m`` union ``offset`` field for 103 the single-planar API, and the same value as returned by the driver 104 in the struct :c:type:`v4l2_plane` ``m`` union 105 ``mem_offset`` field for the multi-planar API. 106 107 108Description 109=========== 110 111The :ref:`mmap() <func-mmap>` function asks to map ``length`` bytes starting at 112``offset`` in the memory of the device specified by ``fd`` into the 113application address space, preferably at address ``start``. This latter 114address is a hint only, and is usually specified as 0. 115 116Suitable length and offset parameters are queried with the 117:ref:`VIDIOC_QUERYBUF` ioctl. Buffers must be 118allocated with the :ref:`VIDIOC_REQBUFS` ioctl 119before they can be queried. 120 121To unmap buffers the :ref:`munmap() <func-munmap>` function is used. 122 123 124Return Value 125============ 126 127On success :ref:`mmap() <func-mmap>` returns a pointer to the mapped buffer. On 128error ``MAP_FAILED`` (-1) is returned, and the ``errno`` variable is set 129appropriately. Possible error codes are: 130 131EBADF 132 ``fd`` is not a valid file descriptor. 133 134EACCES 135 ``fd`` is not open for reading and writing. 136 137EINVAL 138 The ``start`` or ``length`` or ``offset`` are not suitable. (E. g. 139 they are too large, or not aligned on a ``PAGESIZE`` boundary.) 140 141 The ``flags`` or ``prot`` value is not supported. 142 143 No buffers have been allocated with the 144 :ref:`VIDIOC_REQBUFS` ioctl. 145 146ENOMEM 147 Not enough physical or virtual memory was available to complete the 148 request. 149