-
- - .. row 1
-
- - __u32
-
- - ``capability``
-
- -
- - Overlay capability flags set by the driver, see
- :ref:`framebuffer-cap`.
-
- - .. row 2
-
- - __u32
-
- - ``flags``
-
- -
- - Overlay control flags set by application and driver, see
- :ref:`framebuffer-flags`
-
- - .. row 3
-
- - void *
-
- - ``base``
-
- -
- - Physical base address of the framebuffer, that is the address of
- the pixel in the top left corner of the framebuffer. [#f1]_
-
- - .. row 4
-
- -
- -
- -
- - This field is irrelevant to *non-destructive Video Overlays*. For
- *destructive Video Overlays* applications must provide a base
- address. The driver may accept only base addresses which are a
- multiple of two, four or eight bytes. For *Video Output Overlays*
- the driver must return a valid base address, so applications can
- find the corresponding Linux framebuffer device (see
- :ref:`osd`).
-
- - .. row 5
-
- - struct
-
- - ``fmt``
-
- -
- - Layout of the frame buffer.
-
- - .. row 6
-
- -
- - __u32
-
- - ``width``
-
- - Width of the frame buffer in pixels.
-
- - .. row 7
-
- -
- - __u32
-
- - ``height``
-
- - Height of the frame buffer in pixels.
-
- - .. row 8
-
- -
- - __u32
-
- - ``pixelformat``
-
- - The pixel format of the framebuffer.
-
- - .. row 9
-
- -
- -
- -
- - For *non-destructive Video Overlays* this field only defines a
- format for the struct :ref:`v4l2_window <v4l2-window>`
- ``chromakey`` field.
-
- - .. row 10
-
- -
- -
- -
- - For *destructive Video Overlays* applications must initialize this
- field. For *Video Output Overlays* the driver must return a valid
- format.
-
- - .. row 11
-
- -
- -
- -
- - Usually this is an RGB format (for example
- :ref:`V4L2_PIX_FMT_RGB565 <V4L2-PIX-FMT-RGB565>`) but YUV
- formats (only packed YUV formats when chroma keying is used, not
- including ``V4L2_PIX_FMT_YUYV`` and ``V4L2_PIX_FMT_UYVY``) and the
- ``V4L2_PIX_FMT_PAL8`` format are also permitted. The behavior of
- the driver when an application requests a compressed format is
- undefined. See :ref:`pixfmt` for information on pixel formats.
-
- - .. row 12
-
- -
- - enum :ref:`v4l2_field <v4l2-field>`
-
- - ``field``
-
- - Drivers and applications shall ignore this field. If applicable,
- the field order is selected with the
- :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl, using the ``field``
- field of struct :ref:`v4l2_window <v4l2-window>`.
-
- - .. row 13
-
- -
- - __u32
-
- - ``bytesperline``
-
- - Distance in bytes between the leftmost pixels in two adjacent
- lines.
-
- - .. row 14
-
- - :cspan:`3`
-
- This field is irrelevant to *non-destructive Video Overlays*.
-
- For *destructive Video Overlays* both applications and drivers can
- set this field to request padding bytes at the end of each line.
- Drivers however may ignore the requested value, returning
- ``width`` times bytes-per-pixel or a larger value required by the
- hardware. That implies applications can just set this field to
- zero to get a reasonable default.
-
- For *Video Output Overlays* the driver must return a valid value.
-
- Video hardware may access padding bytes, therefore they must
- reside in accessible memory. Consider for example the case where
- padding bytes after the last line of an image cross a system page
- boundary. Capture devices may write padding bytes, the value is
- undefined. Output devices ignore the contents of padding bytes.
-
- When the image format is planar the ``bytesperline`` value applies
- to the first plane and is divided by the same factor as the
- ``width`` field for the other planes. For example the Cb and Cr
- planes of a YUV 4:2:0 image have half as many padding bytes
- following each line as the Y plane. To avoid ambiguities drivers
- must return a ``bytesperline`` value rounded up to a multiple of
- the scale factor.
-
- - .. row 15
-
- -
- - __u32
-
- - ``sizeimage``
-
- - This field is irrelevant to *non-destructive Video Overlays*. For
- *destructive Video Overlays* applications must initialize this
- field. For *Video Output Overlays* the driver must return a valid
- format.
-
- Together with ``base`` it defines the framebuffer memory
- accessible by the driver.
-
- - .. row 16
-
- -
- - enum :ref:`v4l2_colorspace <v4l2-colorspace>`
-
- - ``colorspace``
-
- - This information supplements the ``pixelformat`` and must be set
- by the driver, see :ref:`colorspaces`.
-
- - .. row 17
-
- -
- - __u32
-
- - ``priv``
-
- - Reserved. Drivers and applications must set this field to zero.
-
-
+ * - __u32
+ - ``capability``
+ -
+ - Overlay capability flags set by the driver, see
+ :ref:`framebuffer-cap`.
+ * - __u32
+ - ``flags``
+ -
+ - Overlay control flags set by application and driver, see
+ :ref:`framebuffer-flags`
+ * - void *
+ - ``base``
+ -
+ - Physical base address of the framebuffer, that is the address of
+ the pixel in the top left corner of the framebuffer. [#f1]_
+ * -
+ -
+ -
+ - This field is irrelevant to *non-destructive Video Overlays*. For
+ *destructive Video Overlays* applications must provide a base
+ address. The driver may accept only base addresses which are a
+ multiple of two, four or eight bytes. For *Video Output Overlays*
+ the driver must return a valid base address, so applications can
+ find the corresponding Linux framebuffer device (see
+ :ref:`osd`).
+ * - struct
+ - ``fmt``
+ -
+ - Layout of the frame buffer.
+ * -
+ - __u32
+ - ``width``
+ - Width of the frame buffer in pixels.
+ * -
+ - __u32
+ - ``height``
+ - Height of the frame buffer in pixels.
+ * -
+ - __u32
+ - ``pixelformat``
+ - The pixel format of the framebuffer.
+ * -
+ -
+ -
+ - For *non-destructive Video Overlays* this field only defines a
+ format for the struct :c:type:`v4l2_window`
+ ``chromakey`` field.
+ * -
+ -
+ -
+ - For *destructive Video Overlays* applications must initialize this
+ field. For *Video Output Overlays* the driver must return a valid
+ format.
+ * -
+ -
+ -
+ - Usually this is an RGB format (for example
+ :ref:`V4L2_PIX_FMT_RGB565 <V4L2-PIX-FMT-RGB565>`) but YUV
+ formats (only packed YUV formats when chroma keying is used, not
+ including ``V4L2_PIX_FMT_YUYV`` and ``V4L2_PIX_FMT_UYVY``) and the
+ ``V4L2_PIX_FMT_PAL8`` format are also permitted. The behavior of
+ the driver when an application requests a compressed format is
+ undefined. See :ref:`pixfmt` for information on pixel formats.
+ * -
+ - enum :c:type:`v4l2_field`
+ - ``field``
+ - Drivers and applications shall ignore this field. If applicable,
+ the field order is selected with the
+ :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl, using the ``field``
+ field of struct :c:type:`v4l2_window`.
+ * -
+ - __u32
+ - ``bytesperline``
+ - Distance in bytes between the leftmost pixels in two adjacent
+ lines.
+ * - :cspan:`3`
+
+ This field is irrelevant to *non-destructive Video Overlays*.
+
+ For *destructive Video Overlays* both applications and drivers can
+ set this field to request padding bytes at the end of each line.
+ Drivers however may ignore the requested value, returning
+ ``width`` times bytes-per-pixel or a larger value required by the
+ hardware. That implies applications can just set this field to
+ zero to get a reasonable default.
+
+ For *Video Output Overlays* the driver must return a valid value.
+
+ Video hardware may access padding bytes, therefore they must
+ reside in accessible memory. Consider for example the case where
+ padding bytes after the last line of an image cross a system page
+ boundary. Capture devices may write padding bytes, the value is
+ undefined. Output devices ignore the contents of padding bytes.
+
+ When the image format is planar the ``bytesperline`` value applies
+ to the first plane and is divided by the same factor as the
+ ``width`` field for the other planes. For example the Cb and Cr
+ planes of a YUV 4:2:0 image have half as many padding bytes
+ following each line as the Y plane. To avoid ambiguities drivers
+ must return a ``bytesperline`` value rounded up to a multiple of
+ the scale factor.
+ * -
+ - __u32
+ - ``sizeimage``
+ - This field is irrelevant to *non-destructive Video Overlays*. For
+ *destructive Video Overlays* applications must initialize this
+ field. For *Video Output Overlays* the driver must return a valid
+ format.
+
+ Together with ``base`` it defines the framebuffer memory
+ accessible by the driver.
+ * -
+ - enum :c:type:`v4l2_colorspace`
+ - ``colorspace``
+ - This information supplements the ``pixelformat`` and must be set
+ by the driver, see :ref:`colorspaces`.
+ * -
+ - __u32
+ - ``priv``
+ - Reserved. Drivers and applications must set this field to zero.
+
+
+.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|