Commit bace3db5 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge tag 'media/v4.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media

Pull media updates from Mauro Carvalho Chehab:
 - Added support for some new video formats
 - mn88473 DVB frontend driver got promoted from staging
 - several improvements at the VSP1 driver
 - several cleanups and improvements at the Media Controller
 - added Media Controller support to snd-usb-audio.  Currently, enabled
   only for au0828-based V4L2/DVB boards
 - Several improvements at nuvoton-cir: it now supports wake up codes
 - Add media controller support to em28xx and saa7134 drivers
 - coda driver now accepts NXP distributed firmware files
 - Some legacy SoC camera drivers will be moving to staging, as they're
   outdated and nobody so far is willing to fix and convert them to use
   the current media framework
 - As usual, lots of cleanups, improvements and new board additions.

* tag 'media/v4.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (381 commits)
  media: au0828 disable tuner to demod link in au0828_media_device_register()
  [media] touptek: cast char types on %x printk
  [media] touptek: don't DMA at the stack
  [media] mceusb: use %*ph for small buffer dumps
  [media] v4l: exynos4-is: Drop unneeded check when setting up fimc-lite links
  [media] v4l: vsp1: Check if an entity is a subdev with the right function
  [media] hide unused functions for !MEDIA_CONTROLLER
  [media] em28xx: fix Terratec Grabby AC97 codec detection
  [media] media: add prefixes to interface types
  [media] media: rc: nuvoton: switch attribute wakeup_data to text
  [media] v4l2-ioctl: fix YUV422P pixel format description
  [media] media: fix null pointer dereference in v4l_vb2q_enable_media_source()
  [media] v4l2-mc.h: fix yet more compiler errors
  [media] staging/media: add missing TODO files
  [media] media.h: always start with 1 for the audio entities
  [media] sound/usb: Use meaninful names for goto labels
  [media] v4l2-mc.h: fix compiler warnings
  [media] media: au0828 audio mixer isn't connected to decoder
  [media] sound/usb: Use Media Controller API to share media resources
  [media] dw2102: add support for TeVii S662
  ...
parents 8759957b 8331c055
What: /sys/class/rc/rcN/wakeup_data
Date: Mar 2016
KernelVersion: 4.6
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Description:
Reading this file returns the stored CIR wakeup sequence.
It starts with a pulse, followed by a space, pulse etc.
All values are in microseconds.
The same format can be used to store a wakeup sequence
in the Nuvoton chip by writing to this file.
Note: Some systems reset the stored wakeup sequence to a
factory default on each boot. On such systems store the
wakeup sequence in a file and set it on boot using e.g.
a udev rule.
......@@ -229,6 +229,7 @@ X!Isound/sound_firmware.c
!Iinclude/media/v4l2-dv-timings.h
!Iinclude/media/v4l2-event.h
!Iinclude/media/v4l2-flash-led-class.h
!Iinclude/media/v4l2-mc.h
!Iinclude/media/v4l2-mediabus.h
!Iinclude/media/v4l2-mem2mem.h
!Iinclude/media/v4l2-of.h
......
......@@ -2329,6 +2329,14 @@ to search and match for the present Macroblock (MB) in the reference picture. Th
vertical search range for motion estimation module in video encoder.</entry>
</row>
<row><entry></entry></row>
<row id="v4l2-mpeg-video-force-key-frame">
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME</constant>&nbsp;</entry>
<entry>button</entry>
</row><row><entry spanname="descr">Force a key frame for the next queued buffer. Applicable to encoders.
This is a general, codec-agnostic keyframe control.</entry>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE</constant>&nbsp;</entry>
......@@ -5069,6 +5077,46 @@ interface and may change in the future.</para>
This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors.
</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_DV_TX_IT_CONTENT_TYPE</constant></entry>
<entry id="v4l2-dv-content-type">enum v4l2_dv_it_content_type</entry>
</row>
<row><entry spanname="descr">Configures the IT Content Type
of the transmitted video. This information is sent over HDMI and DisplayPort connectors
as part of the AVI InfoFrame. The term 'IT Content' is used for content that originates
from a computer as opposed to content from a TV broadcast or an analog source. The
enum&nbsp;v4l2_dv_it_content_type defines the possible content types:</entry>
</row>
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_GRAPHICS</constant>&nbsp;</entry>
<entry>Graphics content. Pixel data should be passed unfiltered and without
analog reconstruction.</entry>
</row>
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_PHOTO</constant>&nbsp;</entry>
<entry>Photo content. The content is derived from digital still pictures.
The content should be passed through with minimal scaling and picture
enhancements.</entry>
</row>
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_CINEMA</constant>&nbsp;</entry>
<entry>Cinema content.</entry>
</row>
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_GAME</constant>&nbsp;</entry>
<entry>Game content. Audio and video latency should be minimized.</entry>
</row>
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_NO_ITC</constant>&nbsp;</entry>
<entry>No IT Content information is available and the ITC bit in the AVI
InfoFrame is set to 0.</entry>
</row>
</tbody>
</entrytbl>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_DV_RX_POWER_PRESENT</constant></entry>
<entry>bitmask</entry>
......@@ -5098,6 +5146,16 @@ interface and may change in the future.</para>
This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors.
</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_DV_RX_IT_CONTENT_TYPE</constant></entry>
<entry>enum v4l2_dv_it_content_type</entry>
</row>
<row><entry spanname="descr">Reads the IT Content Type
of the received video. This information is sent over HDMI and DisplayPort connectors
as part of the AVI InfoFrame. The term 'IT Content' is used for content that originates
from a computer as opposed to content from a TV broadcast or an analog source. See
<constant>V4L2_CID_DV_TX_IT_CONTENT_TYPE</constant> for the available content types.</entry>
</row>
<row><entry></entry></row>
</tbody>
</tgroup>
......
......@@ -48,9 +48,6 @@
<refsect1>
<title>Description</title>
<para><emphasis role="bold">NOTE:</emphasis> This new ioctl is programmed to be added on Kernel 4.6. Its definition/arguments may change until its final version.</para>
<para>The typical usage of this ioctl is to call it twice.
On the first call, the structure defined at &media-v2-topology; should
be zeroed. At return, if no errors happen, this ioctl will return the
......
......@@ -80,7 +80,46 @@
</row>
<row>
<entry><constant>MEDIA_ENT_F_TUNER</constant></entry>
<entry>Digital TV, analog TV, radio and/or software radio tuner.</entry>
<entry>Digital TV, analog TV, radio and/or software radio tuner,
with consists on a PLL tuning stage that converts radio
frequency (RF) signal into an Intermediate Frequency (IF).
Modern tuners have internally IF-PLL decoders for audio
and video, but older models have those stages implemented
on separate entities.
</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_IF_VID_DECODER</constant></entry>
<entry>IF-PLL video decoder. It receives the IF from a PLL
and decodes the analog TV video signal. This is commonly
found on some very old analog tuners, like Philips MK3
designs. They all contain a tda9887 (or some software
compatible similar chip, like tda9885). Those devices
use a different I2C address than the tuner PLL.
</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_IF_AUD_DECODER</constant></entry>
<entry>IF-PLL sound decoder. It receives the IF from a PLL
and decodes the analog TV audio signal. This is commonly
found on some very old analog hardware, like Micronas
msp3400, Philips tda9840, tda985x, etc. Those devices
use a different I2C address than the tuner PLL and
should be controlled together with the IF-PLL video
decoder.
</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_AUDIO_CAPTURE</constant></entry>
<entry>Audio Capture Function Entity.</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_AUDIO_PLAYBACK</constant></entry>
<entry>Audio Playback Function Entity.</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_AUDIO_MIXER</constant></entry>
<entry>Audio Mixer Function Entity.</entry>
</row>
</tbody>
</tgroup>
......@@ -162,6 +201,46 @@
<entry>Device node interface for Software Defined Radio (V4L)</entry>
<entry>typically, /dev/swradio?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_PCM_CAPTURE</constant></entry>
<entry>Device node interface for ALSA PCM Capture</entry>
<entry>typically, /dev/snd/pcmC?D?c</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_PCM_PLAYBACK</constant></entry>
<entry>Device node interface for ALSA PCM Playback</entry>
<entry>typically, /dev/snd/pcmC?D?p</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_CONTROL</constant></entry>
<entry>Device node interface for ALSA Control</entry>
<entry>typically, /dev/snd/controlC?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_COMPRESS</constant></entry>
<entry>Device node interface for ALSA Compress</entry>
<entry>typically, /dev/snd/compr?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_RAWMIDI</constant></entry>
<entry>Device node interface for ALSA Raw MIDI</entry>
<entry>typically, /dev/snd/midi?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_HWDEP</constant></entry>
<entry>Device node interface for ALSA Hardware Dependent</entry>
<entry>typically, /dev/snd/hwC?D?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_SEQUENCER</constant></entry>
<entry>Device node interface for ALSA Sequencer</entry>
<entry>typically, /dev/snd/seq</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_TIMER</constant></entry>
<entry>Device node interface for ALSA Timer</entry>
<entry>typically, /dev/snd/timer</entry>
</row>
</tbody>
</tgroup>
</table>
......
<refentry id="V4L2-PIX-FMT-Y12I">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_Y12I ('Y12I')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname><constant>V4L2_PIX_FMT_Y12I</constant></refname>
<refpurpose>Interleaved grey-scale image, e.g. from a stereo-pair</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a grey-scale image with a depth of 12 bits per pixel, but with
pixels from 2 sources interleaved and bit-packed. Each pixel is stored in a
24-bit word in the little-endian order. On a little-endian machine these pixels
can be deinterlaced using</para>
<para>
<programlisting>
__u8 *buf;
left0 = 0xfff &amp; *(__u16 *)buf;
right0 = *(__u16 *)(buf + 1) >> 4;
</programlisting>
</para>
<example>
<title><constant>V4L2_PIX_FMT_Y12I</constant> 2 pixel data stream taking 3 bytes</title>
<formalpara>
<title>Bit-packed representation</title>
<para>pixels cross the byte boundary and have a ratio of 3 bytes for each
interleaved pixel.
<informaltable frame="all">
<tgroup cols="3" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>Y'<subscript>0left[7:0]</subscript></entry>
<entry>Y'<subscript>0right[3:0]</subscript>Y'<subscript>0left[11:8]</subscript></entry>
<entry>Y'<subscript>0right[11:4]</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>
<refentry id="V4L2-PIX-FMT-Y8I">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_Y8I ('Y8I ')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname><constant>V4L2_PIX_FMT_Y8I</constant></refname>
<refpurpose>Interleaved grey-scale image, e.g. from a stereo-pair</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a grey-scale image with a depth of 8 bits per pixel, but with
pixels from 2 sources interleaved. Each pixel is stored in a 16-bit word. E.g.
the R200 RealSense camera stores pixel from the left sensor in lower and from
the right sensor in the higher 8 bits.</para>
<example>
<title><constant>V4L2_PIX_FMT_Y8I</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="9" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00left</subscript></entry>
<entry>Y'<subscript>00right</subscript></entry>
<entry>Y'<subscript>01left</subscript></entry>
<entry>Y'<subscript>01right</subscript></entry>
<entry>Y'<subscript>02left</subscript></entry>
<entry>Y'<subscript>02right</subscript></entry>
<entry>Y'<subscript>03left</subscript></entry>
<entry>Y'<subscript>03right</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>10left</subscript></entry>
<entry>Y'<subscript>10right</subscript></entry>
<entry>Y'<subscript>11left</subscript></entry>
<entry>Y'<subscript>11right</subscript></entry>
<entry>Y'<subscript>12left</subscript></entry>
<entry>Y'<subscript>12right</subscript></entry>
<entry>Y'<subscript>13left</subscript></entry>
<entry>Y'<subscript>13right</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;16:</entry>
<entry>Y'<subscript>20left</subscript></entry>
<entry>Y'<subscript>20right</subscript></entry>
<entry>Y'<subscript>21left</subscript></entry>
<entry>Y'<subscript>21right</subscript></entry>
<entry>Y'<subscript>22left</subscript></entry>
<entry>Y'<subscript>22right</subscript></entry>
<entry>Y'<subscript>23left</subscript></entry>
<entry>Y'<subscript>23right</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;24:</entry>
<entry>Y'<subscript>30left</subscript></entry>
<entry>Y'<subscript>30right</subscript></entry>
<entry>Y'<subscript>31left</subscript></entry>
<entry>Y'<subscript>31right</subscript></entry>
<entry>Y'<subscript>32left</subscript></entry>
<entry>Y'<subscript>32right</subscript></entry>
<entry>Y'<subscript>33left</subscript></entry>
<entry>Y'<subscript>33right</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>
<refentry id="V4L2-PIX-FMT-YUV420M">
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_YUV420M ('YM12')</refentrytitle>
<refentrytitle>V4L2_PIX_FMT_YUV420M ('YM12'), V4L2_PIX_FMT_YVU420M ('YM21')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname> <constant>V4L2_PIX_FMT_YUV420M</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_YUV420</constant>
with planes non contiguous in memory. </refpurpose>
<refname id="V4L2-PIX-FMT-YUV420M"><constant>V4L2_PIX_FMT_YUV420M</constant></refname>
<refname id="V4L2-PIX-FMT-YVU420M"><constant>V4L2_PIX_FMT_YVU420M</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_YUV420</constant> and
<constant>V4L2_PIX_FMT_YVU420</constant> with planes non contiguous
in memory.</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a multi-planar format, as opposed to a packed format.
The three components are separated into three sub- images or planes.
The three components are separated into three sub-images or planes.</para>
The Y plane is first. The Y plane has one byte per pixel. The Cb data
<para>The Y plane is first. The Y plane has one byte per pixel.
For <constant>V4L2_PIX_FMT_YUV420M</constant> the Cb data
constitutes the second plane which is half the width and half
the height of the Y plane (and of the image). Each Cb belongs to four
pixels, a two-by-two square of the image. For example,
Cb<subscript>0</subscript> belongs to Y'<subscript>00</subscript>,
Y'<subscript>01</subscript>, Y'<subscript>10</subscript>, and
Y'<subscript>11</subscript>. The Cr data, just like the Cb plane, is
in the third plane. </para>
in the third plane.</para>
<para><constant>V4L2_PIX_FMT_YVU420M</constant> is the same except
the Cr data is stored in the second plane and the Cb data in the third plane.
</para>
<para>If the Y plane has pad bytes after each row, then the Cb
and Cr planes have half as many pad bytes after their rows. In other
words, two Cx rows (including padding) is exactly as long as one Y row
(including padding).</para>
<para><constant>V4L2_PIX_FMT_YUV420M</constant> is intended to be
<para><constant>V4L2_PIX_FMT_YUV420M</constant> and
<constant>V4L2_PIX_FMT_YVU420M</constant> are intended to be
used only in drivers and applications that support the multi-planar API,
described in <xref linkend="planar-apis"/>. </para>
......
<refentry id="V4L2-PIX-FMT-YVU420M">
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_YVU420M ('YM21')</refentrytitle>
<refentrytitle>V4L2_PIX_FMT_YUV422M ('YM16'), V4L2_PIX_FMT_YVU422M ('YM61')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname> <constant>V4L2_PIX_FMT_YVU420M</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_YVU420</constant>
with planes non contiguous in memory. </refpurpose>
<refname id="V4L2-PIX-FMT-YUV422M"><constant>V4L2_PIX_FMT_YUV422M</constant></refname>
<refname id="V4L2-PIX-FMT-YVU422M"><constant>V4L2_PIX_FMT_YVU422M</constant></refname>
<refpurpose>Planar formats with &frac12; horizontal resolution, also
known as YUV and YVU 4:2:2</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a multi-planar format, as opposed to a packed format.
The three components are separated into three sub-images or planes.
The three components are separated into three sub-images or planes.</para>
The Y plane is first. The Y plane has one byte per pixel. The Cr data
constitutes the second plane which is half the width and half
the height of the Y plane (and of the image). Each Cr belongs to four
pixels, a two-by-two square of the image. For example,
Cr<subscript>0</subscript> belongs to Y'<subscript>00</subscript>,
Y'<subscript>01</subscript>, Y'<subscript>10</subscript>, and
Y'<subscript>11</subscript>. The Cb data, just like the Cr plane, constitutes
the third plane. </para>
<para>The Y plane is first. The Y plane has one byte per pixel.
For <constant>V4L2_PIX_FMT_YUV422M</constant> the Cb data
constitutes the second plane which is half the width of the Y plane (and of the
image). Each Cb belongs to two pixels. For example,
Cb<subscript>0</subscript> belongs to Y'<subscript>00</subscript>,
Y'<subscript>01</subscript>. The Cr data, just like the Cb plane, is
in the third plane. </para>
<para>If the Y plane has pad bytes after each row, then the Cr
and Cb planes have half as many pad bytes after their rows. In other
<para><constant>V4L2_PIX_FMT_YVU422M</constant> is the same except
the Cr data is stored in the second plane and the Cb data in the third plane.
</para>
<para>If the Y plane has pad bytes after each row, then the Cb
and Cr planes have half as many pad bytes after their rows. In other
words, two Cx rows (including padding) is exactly as long as one Y row
(including padding).</para>
<para><constant>V4L2_PIX_FMT_YVU420M</constant> is intended to be
<para><constant>V4L2_PIX_FMT_YUV422M</constant> and
<constant>V4L2_PIX_FMT_YVU422M</constant> are intended to be
used only in drivers and applications that support the multi-planar API,
described in <xref linkend="planar-apis"/>. </para>
<example>
<title><constant>V4L2_PIX_FMT_YVU420M</constant> 4 &times; 4
<title><constant>V4L2_PIX_FMT_YUV422M</constant> 4 &times; 4
pixel image</title>
<formalpara>
......@@ -75,24 +80,44 @@ pixel image</title>
<row><entry></entry></row>
<row>
<entry>start1&nbsp;+&nbsp;0:</entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;2:</entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;4:</entry>
<entry>Cb<subscript>20</subscript></entry>
<entry>Cb<subscript>21</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;6:</entry>
<entry>Cb<subscript>30</subscript></entry>
<entry>Cb<subscript>31</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start2&nbsp;+&nbsp;0:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;2:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;4:</entry>
<entry>Cr<subscript>20</subscript></entry>
<entry>Cr<subscript>21</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;6:</entry>
<entry>Cr<subscript>30</subscript></entry>
<entry>Cr<subscript>31</subscript></entry>
</row>
</tbody>
</tgroup>
......@@ -113,36 +138,23 @@ pixel image</title>
</row>
<row>
<entry>0</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry>
</row>
<row>
<entry>1</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry>
</row>
<row>
<entry>2</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry>
</row>
<row>
<entry>3</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry>
</row>
</tbody>
</tgroup>
......
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_YUV444M ('YM24'), V4L2_PIX_FMT_YVU444M ('YM42')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname id="V4L2-PIX-FMT-YUV444M"><constant>V4L2_PIX_FMT_YUV444M</constant></refname>
<refname id="V4L2-PIX-FMT-YVU444M"><constant>V4L2_PIX_FMT_YVU444M</constant></refname>
<refpurpose>Planar formats with full horizontal resolution, also
known as YUV and YVU 4:4:4</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a multi-planar format, as opposed to a packed format.
The three components are separated into three sub-images or planes.</para>
<para>The Y plane is first. The Y plane has one byte per pixel.
For <constant>V4L2_PIX_FMT_YUV444M</constant> the Cb data
constitutes the second plane which is the same width and height as the Y plane
(and as the image). The Cr data, just like the Cb plane, is in the third plane.
</para>
<para><constant>V4L2_PIX_FMT_YVU444M</constant> is the same except
the Cr data is stored in the second plane and the Cb data in the third plane.
</para>
<para>If the Y plane has pad bytes after each row, then the Cb
and Cr planes have the same number of pad bytes after their rows.</para>
<para><constant>V4L2_PIX_FMT_YUV444M</constant> and
<constant>V4L2_PIX_FMT_YUV444M</constant> are intended to be
used only in drivers and applications that support the multi-planar API,
described in <xref linkend="planar-apis"/>. </para>
<example>
<title><constant>V4L2_PIX_FMT_YUV444M</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start0&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00</subscript></entry>
<entry>Y'<subscript>01</subscript></entry>
<entry>Y'<subscript>02</subscript></entry>
<entry>Y'<subscript>03</subscript></entry>