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