[PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP

[Hyun Kwon]

> -----Original Message-----
> From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com]
> Sent: Tuesday, November 28, 2017 6:44 AM
> To: Hyun Kwon <hyunk at xilinx.com>
> Cc: Daniel Vetter <daniel.vetter at intel.com>; Jani Nikula
> <jani.nikula at linux.intel.com>; Sean Paul <seanpaul at chromium.org>; David
> Airlie <airlied at linux.ie>; dri-devel at lists.freedesktop.org;
> monstr at monstr.eu; Laurent Pinchart
> <laurent.pinchart at ideasonboard.com>; Satish Kumar Nagireddy
> <SATISHNA at xilinx.com>; Jeff Mouroux <jmouroux at xilinx.com>
> Subject: Re: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx
> Video IP
> 
> On Mon, Nov 27, 2017 at 06:27:32PM -0800, Hyun Kwon wrote:
> > From: Jeffrey Mouroux <jmouroux at xilinx.com>
> >
> > The Xilinx Video Mixer and Xilinx Video Framebuffer DMA IP
> > support video memory formats that are not represented in the
> > current DRM fourcc library.  This patch adds those missing
> > fourcc codes.
> >
> > Signed-off-by: Jeffrey Mouroux <jmouroux at xilinx.com>
> > Signed-off-by: Hyun Kwon <hyun.kwon at xilinx.com>
> > ---
> >  include/uapi/drm/drm_fourcc.h | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h
> b/include/uapi/drm/drm_fourcc.h
> > index 3ad838d..83806d5 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -112,6 +112,13 @@ extern "C" {
> >  #define DRM_FORMAT_VYUY		fourcc_code('V', 'Y', 'U', 'Y')
> /* [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
> >
> >  #define DRM_FORMAT_AYUV		fourcc_code('A', 'Y', 'U', 'V')
> /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> > +#define DRM_FORMAT_VUY888	fourcc_code('V', 'U', '2', '4') /* [23:0]
> Cr:Cb:Y little endian */
> > +#define DRM_FORMAT_XVUY8888	fourcc_code('X', 'V', '2', '4') /* [31:0]
> x:Cr:Cb:Y 8:8:8:8 little endian */
> > +#define DRM_FORMAT_XVUY2101010	fourcc_code('X', 'V', '3', '0')
> /* [31:0] x:Cr:Cb:Y 2:10:10:10 little endian */
> > +
> > +/* Grey scale */
> > +#define DRM_FORMAT_Y8		fourcc_code('G', 'R', 'E', 'Y') /* 8-bit
> packed greyscale Y:Y:Y:Y 8:8:8:8 */
> > +#define DRM_FORMAT_Y10		fourcc_code('Y', '1', '0', ' ') /*
> 10-bit packed greyscale X:Y:Y:Y 2:10:10:10 */
> 
> These don't make sense to me. What does it even mean to have Y
> replicated three or four times for each pixel?

Each pixel has one Y component. The comment is to describe how components are stored in 32bit, but I agree it's confusing. Will describe better.

> 
> >
> >  /*
> >   * 2 plane RGB + A
> > @@ -140,6 +147,8 @@ extern "C" {
> >  #define DRM_FORMAT_NV61		fourcc_code('N', 'V', '6', '1')
> /* 2x1 subsampled Cb:Cr plane */
> >  #define DRM_FORMAT_NV24		fourcc_code('N', 'V', '2', '4')
> /* non-subsampled Cr:Cb plane */
> >  #define DRM_FORMAT_NV42		fourcc_code('N', 'V', '4', '2')
> /* non-subsampled Cb:Cr plane */
> > +#define DRM_FORMAT_XV15		fourcc_code('X', 'V', '1', '5')
> /* 2x2 subsampled Cr:Cb plane 2:10:10:10 */
> > +#define DRM_FORMAT_XV20		fourcc_code('X', 'V', '2', '0')
> /* 2x1 subsampled Cr:Cb plane 2:10:10:10 */
> 
> Huh. Where are the Cb:Cr in that 2:10:10:10 layout?
> 
> Better docs please.

Sure. Will add more details on how components are laid out.

Thanks,
-hyun

> 
> >
> >  /*
> >   * 3 plane YCbCr
> > --
> > 2.7.4
> >
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> --
> Ville Syrjälä
> Intel OTC