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
next prev parent 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: linkBe 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.