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

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