Documentation/media/uapi/v4l/func-mmap.rst

   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/media/uapi/fdl-appendix.rst.
   7 ..
   8 .. TODO: replace it to GFDL-1.1-or-later WITH no-invariant-sections
   9
  10 .. _func-mmap:
  11
  12 ***********
  13 V4L2 mmap()
  14 ***********
  15
  16 Name
  17 ====
  18
  19 v4l2-mmap - Map device memory into application address space
  20
  21
  22 Synopsis
  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
  34 Arguments
  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
 108 Description
 109 ===========
 110
 111 The :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
 113 application address space, preferably at address ``start``. This latter
 114 address is a hint only, and is usually specified as 0.
 115
 116 Suitable length and offset parameters are queried with the
 117 :ref:`VIDIOC_QUERYBUF` ioctl. Buffers must be
 118 allocated with the :ref:`VIDIOC_REQBUFS` ioctl
 119 before they can be queried.
 120
 121 To unmap buffers the :ref:`munmap() <func-munmap>` function is used.
 122
 123
 124 Return Value
 125 ============
 126
 127 On success :ref:`mmap() <func-mmap>` returns a pointer to the mapped buffer. On
 128 error ``MAP_FAILED`` (-1) is returned, and the ``errno`` variable is set
 129 appropriately. Possible error codes are:
 130
 131 EBADF
 132     ``fd`` is not a valid file descriptor.
 133
 134 EACCES
 135     ``fd`` is not open for reading and writing.
 136
 137 EINVAL
 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
 146 ENOMEM
 147     Not enough physical or virtual memory was available to complete the
 148     request.