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