All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Jacopo Mondi <jacopo@jmondi.org>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org,
	linux-renesas-soc@vger.kernel.org,
	Maxime Ripard <maxime.ripard@bootlin.com>
Subject: Re: [PATCH 1/9] v4l: Add definitions for missing 32-bit RGB formats
Date: Tue, 2 Apr 2019 15:12:00 +0300	[thread overview]
Message-ID: <20190402121200.GX4805@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20190328131543.zlito5lm3n7mjyls@uno.localdomain>

Hi Jacopo,

On Thu, Mar 28, 2019 at 02:15:43PM +0100, Jacopo Mondi wrote:
> On Thu, Mar 28, 2019 at 09:07:15AM +0200, Laurent Pinchart wrote:
> > The V4L2 API is missing the 32-bit RGB formats for the ABGR, XBGR, RGBA
> > and RGBX component orders. Add them, using the same 4CCs as DRM.
> >
> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > ---
> >  .../media/uapi/v4l/pixfmt-packed-rgb.rst      | 160 ++++++++++++++++++
> >  include/uapi/linux/videodev2.h                |   4 +
> >  2 files changed, 164 insertions(+)
> >
> > diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst b/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst
> > index 6b3781c04dd5..055f9c89e787 100644
> > --- a/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst
> > +++ b/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst
> > @@ -453,6 +453,166 @@ next to each other in memory.
> >        - r\ :sub:`1`
> >        - r\ :sub:`0`
> >
> > +      -
> > +      -
> > +      -
> > +      -
> > +      -
> > +      -
> > +      -
> > +      -
> > +    * .. _V4L2-PIX-FMT-BGRA32:
> > +
> > +      - ``V4L2_PIX_FMT_BGRA32``
> > +      - 'RA24'
> > +
> > +      - a\ :sub:`7`
> > +      - a\ :sub:`6`
> > +      - a\ :sub:`5`
> > +      - a\ :sub:`4`
> > +      - a\ :sub:`3`
> > +      - a\ :sub:`2`
> > +      - a\ :sub:`1`
> > +      - a\ :sub:`0`
> > +
> > +      - b\ :sub:`7`
> > +      - b\ :sub:`6`
> > +      - b\ :sub:`5`
> > +      - b\ :sub:`4`
> > +      - b\ :sub:`3`
> > +      - b\ :sub:`2`
> > +      - b\ :sub:`1`
> > +      - b\ :sub:`0`
> > +
> > +      - g\ :sub:`7`
> > +      - g\ :sub:`6`
> > +      - g\ :sub:`5`
> > +      - g\ :sub:`4`
> > +      - g\ :sub:`3`
> > +      - g\ :sub:`2`
> > +      - g\ :sub:`1`
> > +      - g\ :sub:`0`
> > +
> > +      - r\ :sub:`7`
> > +      - r\ :sub:`6`
> > +      - r\ :sub:`5`
> > +      - r\ :sub:`4`
> > +      - r\ :sub:`3`
> > +      - r\ :sub:`2`
> > +      - r\ :sub:`1`
> > +      - r\ :sub:`0`
> > +    * .. _V4L2-PIX-FMT-BGRX32:
> > +
> > +      - ``V4L2_PIX_FMT_BGRX32``
> > +      - 'RX24'
> > +
> > +      -
> > +      -
> > +      -
> > +      -
> > +      -
> > +      -
> > +      -
> > +      -
> > +
> > +      - b\ :sub:`7`
> > +      - b\ :sub:`6`
> > +      - b\ :sub:`5`
> > +      - b\ :sub:`4`
> > +      - b\ :sub:`3`
> > +      - b\ :sub:`2`
> > +      - b\ :sub:`1`
> > +      - b\ :sub:`0`
> > +
> > +      - g\ :sub:`7`
> > +      - g\ :sub:`6`
> > +      - g\ :sub:`5`
> > +      - g\ :sub:`4`
> > +      - g\ :sub:`3`
> > +      - g\ :sub:`2`
> > +      - g\ :sub:`1`
> > +      - g\ :sub:`0`
> > +
> > +      - r\ :sub:`7`
> > +      - r\ :sub:`6`
> > +      - r\ :sub:`5`
> > +      - r\ :sub:`4`
> > +      - r\ :sub:`3`
> > +      - r\ :sub:`2`
> > +      - r\ :sub:`1`
> > +      - r\ :sub:`0`
> > +    * .. _V4L2-PIX-FMT-RGBA32:
> > +
> > +      - ``V4L2_PIX_FMT_RGBA32``
> > +      - 'AB24'
> > +
> > +      - r\ :sub:`7`
> > +      - r\ :sub:`6`
> > +      - r\ :sub:`5`
> > +      - r\ :sub:`4`
> > +      - r\ :sub:`3`
> > +      - r\ :sub:`2`
> > +      - r\ :sub:`1`
> > +      - r\ :sub:`0`
> > +
> > +      - g\ :sub:`7`
> > +      - g\ :sub:`6`
> > +      - g\ :sub:`5`
> > +      - g\ :sub:`4`
> > +      - g\ :sub:`3`
> > +      - g\ :sub:`2`
> > +      - g\ :sub:`1`
> > +      - g\ :sub:`0`
> > +
> > +      - b\ :sub:`7`
> > +      - b\ :sub:`6`
> > +      - b\ :sub:`5`
> > +      - b\ :sub:`4`
> > +      - b\ :sub:`3`
> > +      - b\ :sub:`2`
> > +      - b\ :sub:`1`
> > +      - b\ :sub:`0`
> > +
> > +      - a\ :sub:`7`
> > +      - a\ :sub:`6`
> > +      - a\ :sub:`5`
> > +      - a\ :sub:`4`
> > +      - a\ :sub:`3`
> > +      - a\ :sub:`2`
> > +      - a\ :sub:`1`
> > +      - a\ :sub:`0`
> > +    * .. _V4L2-PIX-FMT-RGBX32:
> > +
> > +      - ``V4L2_PIX_FMT_RGBX32``
> > +      - 'XB24'
> > +
> > +      - r\ :sub:`7`
> > +      - r\ :sub:`6`
> > +      - r\ :sub:`5`
> > +      - r\ :sub:`4`
> > +      - r\ :sub:`3`
> > +      - r\ :sub:`2`
> > +      - r\ :sub:`1`
> > +      - r\ :sub:`0`
> > +
> > +      - g\ :sub:`7`
> > +      - g\ :sub:`6`
> > +      - g\ :sub:`5`
> > +      - g\ :sub:`4`
> > +      - g\ :sub:`3`
> > +      - g\ :sub:`2`
> > +      - g\ :sub:`1`
> > +      - g\ :sub:`0`
> > +
> > +      - b\ :sub:`7`
> > +      - b\ :sub:`6`
> > +      - b\ :sub:`5`
> > +      - b\ :sub:`4`
> > +      - b\ :sub:`3`
> > +      - b\ :sub:`2`
> > +      - b\ :sub:`1`
> > +      - b\ :sub:`0`
> > +
> 
> I'm trying to compare these with the existing 32-bit RGB formats in
> pixfmt-packed-rgb.rst and I can't get how the orderig of components is
> defined.

Pixel formats are all a big mess :-)

> Ie your definitions here:
> 
>         bytes:  B0      B1      B2      B3
> BGRA32          A       B       G       R
> BGRX32          x       B       G       R
> RGBA32          R       G       B       A
> RGBX32          R       G       B       x
> 
> In the existing documentation:
> ABGR32          B       G       R       A
> XBGR32          B       G       R       x
> ARGB32          A       R       G       B
> XRGB32          x       R       G       B

> So you're adding two BGR/RGB variations with 'X' or 'A' moved from the
> first (for RGB) or last (for BGR) bytes to the last (for RGB) or first
> (for BGR) bytes.
> 
> I cannot see a clear pattern (it seems RGB is ordered as you read the
> components, while BGR is inverted?) so I assume the definition of the
> component ordering scheme comes from a standard, does it? A reference
> would help checking for errors :)

The existing formats are pretty inconsistent. I suppose ARGB and XRGB
were added first, with the format names corresponding to the pixel order
in memory. Then a need to support BGRA and BGRX arose, and the format
names were set to ABGR32 and XBGR32 instead of BGRA32 and BGRX32.
Unfortuantely we can't fix this as it's an ABI, so I had to follow the
same scheme for the new formats. RGBA and RGBX are fine as the RGBA31
and RGBX32 names were free, but for ABGR and XBGR I had to use the
BGRA32 and BGRX32 names.

> >        -
> >        -
> >        -
> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> > index 1db220da3bcc..4e5222726719 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -528,7 +528,11 @@ struct v4l2_pix_format {
> >  #define V4L2_PIX_FMT_BGR32   v4l2_fourcc('B', 'G', 'R', '4') /* 32  BGR-8-8-8-8   */
> >  #define V4L2_PIX_FMT_ABGR32  v4l2_fourcc('A', 'R', '2', '4') /* 32  BGRA-8-8-8-8  */
> >  #define V4L2_PIX_FMT_XBGR32  v4l2_fourcc('X', 'R', '2', '4') /* 32  BGRX-8-8-8-8  */
> > +#define V4L2_PIX_FMT_BGRA32  v4l2_fourcc('R', 'A', '2', '4') /* 32  ABGR-8-8-8-8  */
> > +#define V4L2_PIX_FMT_BGRX32  v4l2_fourcc('R', 'X', '2', '4') /* 32  XBGR-8-8-8-8  */
> >  #define V4L2_PIX_FMT_RGB32   v4l2_fourcc('R', 'G', 'B', '4') /* 32  RGB-8-8-8-8   */
> > +#define V4L2_PIX_FMT_RGBA32  v4l2_fourcc('A', 'B', '2', '4') /* 32  RGBA-8-8-8-8  */
> > +#define V4L2_PIX_FMT_RGBX32  v4l2_fourcc('X', 'B', '2', '4') /* 32  RGBX-8-8-8-8  */
> >  #define V4L2_PIX_FMT_ARGB32  v4l2_fourcc('B', 'A', '2', '4') /* 32  ARGB-8-8-8-8  */
> >  #define V4L2_PIX_FMT_XRGB32  v4l2_fourcc('B', 'X', '2', '4') /* 32  XRGB-8-8-8-8  */
> >

-- 
Regards,

Laurent Pinchart

WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Jacopo Mondi <jacopo@jmondi.org>
Cc: linux-renesas-soc@vger.kernel.org,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org
Subject: Re: [PATCH 1/9] v4l: Add definitions for missing 32-bit RGB formats
Date: Tue, 2 Apr 2019 15:12:00 +0300	[thread overview]
Message-ID: <20190402121200.GX4805@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20190328131543.zlito5lm3n7mjyls@uno.localdomain>

Hi Jacopo,

On Thu, Mar 28, 2019 at 02:15:43PM +0100, Jacopo Mondi wrote:
> On Thu, Mar 28, 2019 at 09:07:15AM +0200, Laurent Pinchart wrote:
> > The V4L2 API is missing the 32-bit RGB formats for the ABGR, XBGR, RGBA
> > and RGBX component orders. Add them, using the same 4CCs as DRM.
> >
> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > ---
> >  .../media/uapi/v4l/pixfmt-packed-rgb.rst      | 160 ++++++++++++++++++
> >  include/uapi/linux/videodev2.h                |   4 +
> >  2 files changed, 164 insertions(+)
> >
> > diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst b/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst
> > index 6b3781c04dd5..055f9c89e787 100644
> > --- a/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst
> > +++ b/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst
> > @@ -453,6 +453,166 @@ next to each other in memory.
> >        - r\ :sub:`1`
> >        - r\ :sub:`0`
> >
> > +      -
> > +      -
> > +      -
> > +      -
> > +      -
> > +      -
> > +      -
> > +      -
> > +    * .. _V4L2-PIX-FMT-BGRA32:
> > +
> > +      - ``V4L2_PIX_FMT_BGRA32``
> > +      - 'RA24'
> > +
> > +      - a\ :sub:`7`
> > +      - a\ :sub:`6`
> > +      - a\ :sub:`5`
> > +      - a\ :sub:`4`
> > +      - a\ :sub:`3`
> > +      - a\ :sub:`2`
> > +      - a\ :sub:`1`
> > +      - a\ :sub:`0`
> > +
> > +      - b\ :sub:`7`
> > +      - b\ :sub:`6`
> > +      - b\ :sub:`5`
> > +      - b\ :sub:`4`
> > +      - b\ :sub:`3`
> > +      - b\ :sub:`2`
> > +      - b\ :sub:`1`
> > +      - b\ :sub:`0`
> > +
> > +      - g\ :sub:`7`
> > +      - g\ :sub:`6`
> > +      - g\ :sub:`5`
> > +      - g\ :sub:`4`
> > +      - g\ :sub:`3`
> > +      - g\ :sub:`2`
> > +      - g\ :sub:`1`
> > +      - g\ :sub:`0`
> > +
> > +      - r\ :sub:`7`
> > +      - r\ :sub:`6`
> > +      - r\ :sub:`5`
> > +      - r\ :sub:`4`
> > +      - r\ :sub:`3`
> > +      - r\ :sub:`2`
> > +      - r\ :sub:`1`
> > +      - r\ :sub:`0`
> > +    * .. _V4L2-PIX-FMT-BGRX32:
> > +
> > +      - ``V4L2_PIX_FMT_BGRX32``
> > +      - 'RX24'
> > +
> > +      -
> > +      -
> > +      -
> > +      -
> > +      -
> > +      -
> > +      -
> > +      -
> > +
> > +      - b\ :sub:`7`
> > +      - b\ :sub:`6`
> > +      - b\ :sub:`5`
> > +      - b\ :sub:`4`
> > +      - b\ :sub:`3`
> > +      - b\ :sub:`2`
> > +      - b\ :sub:`1`
> > +      - b\ :sub:`0`
> > +
> > +      - g\ :sub:`7`
> > +      - g\ :sub:`6`
> > +      - g\ :sub:`5`
> > +      - g\ :sub:`4`
> > +      - g\ :sub:`3`
> > +      - g\ :sub:`2`
> > +      - g\ :sub:`1`
> > +      - g\ :sub:`0`
> > +
> > +      - r\ :sub:`7`
> > +      - r\ :sub:`6`
> > +      - r\ :sub:`5`
> > +      - r\ :sub:`4`
> > +      - r\ :sub:`3`
> > +      - r\ :sub:`2`
> > +      - r\ :sub:`1`
> > +      - r\ :sub:`0`
> > +    * .. _V4L2-PIX-FMT-RGBA32:
> > +
> > +      - ``V4L2_PIX_FMT_RGBA32``
> > +      - 'AB24'
> > +
> > +      - r\ :sub:`7`
> > +      - r\ :sub:`6`
> > +      - r\ :sub:`5`
> > +      - r\ :sub:`4`
> > +      - r\ :sub:`3`
> > +      - r\ :sub:`2`
> > +      - r\ :sub:`1`
> > +      - r\ :sub:`0`
> > +
> > +      - g\ :sub:`7`
> > +      - g\ :sub:`6`
> > +      - g\ :sub:`5`
> > +      - g\ :sub:`4`
> > +      - g\ :sub:`3`
> > +      - g\ :sub:`2`
> > +      - g\ :sub:`1`
> > +      - g\ :sub:`0`
> > +
> > +      - b\ :sub:`7`
> > +      - b\ :sub:`6`
> > +      - b\ :sub:`5`
> > +      - b\ :sub:`4`
> > +      - b\ :sub:`3`
> > +      - b\ :sub:`2`
> > +      - b\ :sub:`1`
> > +      - b\ :sub:`0`
> > +
> > +      - a\ :sub:`7`
> > +      - a\ :sub:`6`
> > +      - a\ :sub:`5`
> > +      - a\ :sub:`4`
> > +      - a\ :sub:`3`
> > +      - a\ :sub:`2`
> > +      - a\ :sub:`1`
> > +      - a\ :sub:`0`
> > +    * .. _V4L2-PIX-FMT-RGBX32:
> > +
> > +      - ``V4L2_PIX_FMT_RGBX32``
> > +      - 'XB24'
> > +
> > +      - r\ :sub:`7`
> > +      - r\ :sub:`6`
> > +      - r\ :sub:`5`
> > +      - r\ :sub:`4`
> > +      - r\ :sub:`3`
> > +      - r\ :sub:`2`
> > +      - r\ :sub:`1`
> > +      - r\ :sub:`0`
> > +
> > +      - g\ :sub:`7`
> > +      - g\ :sub:`6`
> > +      - g\ :sub:`5`
> > +      - g\ :sub:`4`
> > +      - g\ :sub:`3`
> > +      - g\ :sub:`2`
> > +      - g\ :sub:`1`
> > +      - g\ :sub:`0`
> > +
> > +      - b\ :sub:`7`
> > +      - b\ :sub:`6`
> > +      - b\ :sub:`5`
> > +      - b\ :sub:`4`
> > +      - b\ :sub:`3`
> > +      - b\ :sub:`2`
> > +      - b\ :sub:`1`
> > +      - b\ :sub:`0`
> > +
> 
> I'm trying to compare these with the existing 32-bit RGB formats in
> pixfmt-packed-rgb.rst and I can't get how the orderig of components is
> defined.

Pixel formats are all a big mess :-)

> Ie your definitions here:
> 
>         bytes:  B0      B1      B2      B3
> BGRA32          A       B       G       R
> BGRX32          x       B       G       R
> RGBA32          R       G       B       A
> RGBX32          R       G       B       x
> 
> In the existing documentation:
> ABGR32          B       G       R       A
> XBGR32          B       G       R       x
> ARGB32          A       R       G       B
> XRGB32          x       R       G       B

> So you're adding two BGR/RGB variations with 'X' or 'A' moved from the
> first (for RGB) or last (for BGR) bytes to the last (for RGB) or first
> (for BGR) bytes.
> 
> I cannot see a clear pattern (it seems RGB is ordered as you read the
> components, while BGR is inverted?) so I assume the definition of the
> component ordering scheme comes from a standard, does it? A reference
> would help checking for errors :)

The existing formats are pretty inconsistent. I suppose ARGB and XRGB
were added first, with the format names corresponding to the pixel order
in memory. Then a need to support BGRA and BGRX arose, and the format
names were set to ABGR32 and XBGR32 instead of BGRA32 and BGRX32.
Unfortuantely we can't fix this as it's an ABI, so I had to follow the
same scheme for the new formats. RGBA and RGBX are fine as the RGBA31
and RGBX32 names were free, but for ABGR and XBGR I had to use the
BGRA32 and BGRX32 names.

> >        -
> >        -
> >        -
> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> > index 1db220da3bcc..4e5222726719 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -528,7 +528,11 @@ struct v4l2_pix_format {
> >  #define V4L2_PIX_FMT_BGR32   v4l2_fourcc('B', 'G', 'R', '4') /* 32  BGR-8-8-8-8   */
> >  #define V4L2_PIX_FMT_ABGR32  v4l2_fourcc('A', 'R', '2', '4') /* 32  BGRA-8-8-8-8  */
> >  #define V4L2_PIX_FMT_XBGR32  v4l2_fourcc('X', 'R', '2', '4') /* 32  BGRX-8-8-8-8  */
> > +#define V4L2_PIX_FMT_BGRA32  v4l2_fourcc('R', 'A', '2', '4') /* 32  ABGR-8-8-8-8  */
> > +#define V4L2_PIX_FMT_BGRX32  v4l2_fourcc('R', 'X', '2', '4') /* 32  XBGR-8-8-8-8  */
> >  #define V4L2_PIX_FMT_RGB32   v4l2_fourcc('R', 'G', 'B', '4') /* 32  RGB-8-8-8-8   */
> > +#define V4L2_PIX_FMT_RGBA32  v4l2_fourcc('A', 'B', '2', '4') /* 32  RGBA-8-8-8-8  */
> > +#define V4L2_PIX_FMT_RGBX32  v4l2_fourcc('X', 'B', '2', '4') /* 32  RGBX-8-8-8-8  */
> >  #define V4L2_PIX_FMT_ARGB32  v4l2_fourcc('B', 'A', '2', '4') /* 32  ARGB-8-8-8-8  */
> >  #define V4L2_PIX_FMT_XRGB32  v4l2_fourcc('B', 'X', '2', '4') /* 32  XRGB-8-8-8-8  */
> >

-- 
Regards,

Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2019-04-02 12:12 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-28  7:07 [PATCH 0/9] R-Car DU: Add missing RGB pixel formats Laurent Pinchart
2019-03-28  7:07 ` Laurent Pinchart
2019-03-28  7:07 ` [PATCH 1/9] v4l: Add definitions for missing 32-bit RGB formats Laurent Pinchart
2019-03-28  7:07   ` Laurent Pinchart
2019-03-28 13:15   ` Jacopo Mondi
2019-03-28 13:15     ` Jacopo Mondi
2019-04-02 12:12     ` Laurent Pinchart [this message]
2019-04-02 12:12       ` Laurent Pinchart
2019-04-04 16:02       ` Jacopo Mondi
2019-04-04 16:02         ` Jacopo Mondi
2019-03-28  7:07 ` [PATCH 2/9] v4l: Add definitions for missing 16-bit RGB4444 formats Laurent Pinchart
2019-03-28  7:07   ` Laurent Pinchart
2019-04-04 16:00   ` Jacopo Mondi
2019-04-04 16:00     ` Jacopo Mondi
2019-04-18  5:57     ` Laurent Pinchart
2019-04-18  5:57       ` Laurent Pinchart
2019-07-09 12:56   ` Hans Verkuil
2019-07-09 12:56     ` Hans Verkuil
2019-03-28  7:07 ` [PATCH 3/9] v4l: Add definitions for missing 16-bit RGB555 formats Laurent Pinchart
2019-03-28  7:07   ` Laurent Pinchart
2019-04-04 15:57   ` Jacopo Mondi
2019-04-04 15:57     ` Jacopo Mondi
2019-04-18  6:25     ` Laurent Pinchart
2019-04-18  6:25       ` Laurent Pinchart
2019-04-18  6:27   ` [PATCH v1.1 " Laurent Pinchart
2019-04-18  6:27     ` Laurent Pinchart
2019-04-23 11:53     ` Jacopo Mondi
2019-04-23 11:53       ` Jacopo Mondi
2019-03-28  7:07 ` [PATCH 4/9] media: vsp1: Add support for missing 32-bit RGB formats Laurent Pinchart
2019-03-28  7:07   ` Laurent Pinchart
2019-04-04 17:39   ` Jacopo Mondi
2019-04-04 17:39     ` Jacopo Mondi
2019-04-18  6:06     ` Laurent Pinchart
2019-04-18  6:06       ` Laurent Pinchart
2019-04-23 13:21       ` Jacopo Mondi
2019-04-23 13:21         ` Jacopo Mondi
2019-04-23 14:10         ` Laurent Pinchart
2019-04-23 14:10           ` Laurent Pinchart
2019-03-28  7:07 ` [PATCH 5/9] media: vsp1: Add support for missing 16-bit RGB444 formats Laurent Pinchart
2019-03-28  7:07   ` Laurent Pinchart
2019-04-23 13:38   ` Jacopo Mondi
2019-04-23 13:38     ` Jacopo Mondi
2019-03-28  7:07 ` [PATCH 6/9] media: vsp1: Add support for missing 16-bit RGB555 formats Laurent Pinchart
2019-03-28  7:07   ` Laurent Pinchart
2019-04-23 13:55   ` Jacopo Mondi
2019-04-23 13:55     ` Jacopo Mondi
2019-04-23 14:46     ` Laurent Pinchart
2019-04-23 14:46       ` Laurent Pinchart
2019-04-23 16:56       ` Jacopo Mondi
2019-04-23 16:56         ` Jacopo Mondi
2019-04-23 19:29         ` Laurent Pinchart
2019-04-23 19:29           ` Laurent Pinchart
2019-03-28  7:07 ` [PATCH 7/9] drm: rcar-du: Add support for missing 32-bit RGB formats Laurent Pinchart
2019-03-28  7:07   ` Laurent Pinchart
2019-04-23 14:05   ` Jacopo Mondi
2019-04-23 14:05     ` Jacopo Mondi
2019-03-28  7:07 ` [PATCH 8/9] drm: rcar-du: Add support for missing 16-bit RGB4444 formats Laurent Pinchart
2019-03-28  7:07   ` Laurent Pinchart
2019-04-23 14:06   ` Jacopo Mondi
2019-04-23 14:06     ` Jacopo Mondi
2019-03-28  7:07 ` [PATCH 9/9] drm: rcar-du: Add support for missing 16-bit RGB1555 formats Laurent Pinchart
2019-03-28  7:07   ` Laurent Pinchart
2019-04-23 14:09   ` Jacopo Mondi
2019-04-23 14:09     ` Jacopo Mondi
2019-04-20 13:09 ` [PATCH 0/9] R-Car DU: Add missing RGB pixel formats Laurent Pinchart
2019-04-20 13:09   ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190402121200.GX4805@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jacopo@jmondi.org \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=maxime.ripard@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.