Re: [RFC v2 02/10] drm: drm_fourcc: Introduce macro-pixel info to drm_format_info

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Daniel,

On Tue, 2018-01-30 at 02:22:40 -0800, Daniel Vetter wrote:
> On Thu, Jan 25, 2018 at 06:03:59PM -0800, Hyun Kwon wrote:
> > Multiple pixels can be grouped as a single unit and form a 'macro-pixel'.
> > This is to model formats where multiple pixels are stored together
> > in a specific way, likely byte-algined. For example, if 3 - 10 bit
> > pixels are stored in 32 bit, the 32 bit stroage can be treated as
> > a single macro-pixel with 3 pixels. This aligns non-byte addressable
> > formats with drm core where bpp is expected to be multiple of 8 bit.
> > 
> > Add 'ppm', pixels per macro-pixel, to note how many pixels are grouped
> > in a macro-pixel. 'bpm', bits per macro-pixel, specifies how many bits
> > are in a macro-pixel as there can be some extra padding bits.
> 
> Should we mandate that macro-pixels are always byte-aligned? This would
> mean cpm for characters per macro-pixel would be more meaningful.
> 

Agreed. That would simplify stuff and be more clean.

> > 
> > Signed-off-by: Hyun Kwon <hyun.kwon@xxxxxxxxxx>
> > ---
> > v2
> > - Introduce macro-pixel over scaling factors
> > ---
> > ---
> >  drivers/gpu/drm/drm_fourcc.c | 136 +++++++++++++++++++++----------------------
> >  include/drm/drm_fourcc.h     |   9 +++
> >  2 files changed, 77 insertions(+), 68 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index b891fe0..8fc1e35 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -105,74 +105,74 @@ EXPORT_SYMBOL(drm_get_format_name);
> >  const struct drm_format_info *__drm_format_info(u32 format)
> >  {
> >  	static const struct drm_format_info formats[] = {
> > -		{ .format = DRM_FORMAT_C8,		.depth = 8,  .num_planes = 1, .cpp = { 1, 0, 0 }, .bpp = { 8, 0, 0 },  .hsub = 1, .vsub = 1 },
> > -		{ .format = DRM_FORMAT_RGB332,		.depth = 8,  .num_planes = 1, .cpp = { 1, 0, 0 }, .bpp = { 8, 0, 0 },  .hsub = 1, .vsub = 1 },
> > -		{ .format = DRM_FORMAT_BGR233,		.depth = 8,  .num_planes = 1, .cpp = { 1, 0, 0 }, .bpp = { 8, 0, 0 },  .hsub = 1, .vsub = 1 },
> > -		{ .format = DRM_FORMAT_XRGB4444,	.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1 },
> > -		{ .format = DRM_FORMAT_XBGR4444,	.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1 },
> > -		{ .format = DRM_FORMAT_RGBX4444,	.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1 },
> > -		{ .format = DRM_FORMAT_BGRX4444,	.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1 },
> > -		{ .format = DRM_FORMAT_ARGB4444,	.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1 },
> > -		{ .format = DRM_FORMAT_ABGR4444,	.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1 },
> > -		{ .format = DRM_FORMAT_RGBA4444,	.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1 },
> > -		{ .format = DRM_FORMAT_BGRA4444,	.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1 },

[snip]

> +		{ .format = DRM_FORMAT_NV16,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .bpp = { 8, 16, 0 }, .ppm =  { 1, 1, 0 }, .bpm = { 8, 16, 0 }, .hsub = 2, .vsub = 1 },
> > +		{ .format = DRM_FORMAT_NV61,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .bpp = { 8, 16, 0 }, .ppm =  { 1, 1, 0 }, .bpm = { 8, 16, 0 }, .hsub = 2, .vsub = 1 },
> > +		{ .format = DRM_FORMAT_NV24,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .bpp = { 8, 16, 0 }, .ppm =  { 1, 1, 0 }, .bpm = { 8, 16, 0 }, .hsub = 1, .vsub = 1 },
> > +		{ .format = DRM_FORMAT_NV42,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .bpp = { 8, 16, 0 }, .ppm =  { 1, 1, 0 }, .bpm = { 8, 16, 0 }, .hsub = 1, .vsub = 1 },
> > +		{ .format = DRM_FORMAT_YUYV,		.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .ppm =  { 1, 0, 0 }, .bpm = { 16, 0, 0 }, .hsub = 2, .vsub = 1 },
> > +		{ .format = DRM_FORMAT_YVYU,		.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .ppm =  { 1, 0, 0 }, .bpm = { 16, 0, 0 }, .hsub = 2, .vsub = 1 },
> > +		{ .format = DRM_FORMAT_UYVY,		.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .ppm =  { 1, 0, 0 }, .bpm = { 16, 0, 0 }, .hsub = 2, .vsub = 1 },
> > +		{ .format = DRM_FORMAT_VYUY,		.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .ppm =  { 1, 0, 0 }, .bpm = { 16, 0, 0 }, .hsub = 2, .vsub = 1 },
> > +		{ .format = DRM_FORMAT_AYUV,		.depth = 0,  .num_planes = 1, .cpp = { 4, 0, 0 }, .bpp = { 32, 0, 0 }, .ppm =  { 1, 0, 0 }, .bpm = { 32, 0, 0 }, .hsub = 1, .vsub = 1 },
> 
> Ugh. I think some macros for the common/simple cases would be useful.
> There's also other people trying to add more information to these (like
> alpha bits), refactoring this slightly would help I think.
> 
> >  	};
> >  
> >  	unsigned int i;
> > diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> > index 752bd43..64038e9 100644
> > --- a/include/drm/drm_fourcc.h
> > +++ b/include/drm/drm_fourcc.h
> > @@ -37,6 +37,13 @@ struct drm_mode_fb_cmd2;
> >   * @num_planes: Number of color planes (1 to 3)
> >   * @cpp: Number of bytes per pixel (per plane)
> >   * @bpp: Number of bits per pixel (per plane)
> > + * @ppm: Number of pixels per macro-pixel (per plane). A macro-pixel is
> > + *	composed of multiple pixels, possibly with some padding bits
> > + *	around pixels. For example, some 10 bit format has 3 components
> > + *	in every 32 bit, where 3 10bit components are followed by 2 bit padding.
> > + * @bpm: Number of bits per macro-pixel (per plane). Bits per macro-pixel.
> > + *	The value is different from bpp * ppm if a macro-pixel has
> > + *	extra padding bits.
> 
> Please switch the entire kernel-doc for this structure to the in-line
> member kerneldoc style. That's much more readable and groups the comments
> closer to the members.

Sure, will do.

> 
> Also I think we should write these out. cpp/bpp are well-known, ppm and
> bpm aren't (and bpm usually means beats per minute, so even more
> confusing).

Would having more explanation in the member descriptions abvoe, maybe with
some renaming, be sufficient? or did you mean different write-up?

Thanks,
-hyun

> -Daniel
> 
> >   * @hsub: Horizontal chroma subsampling factor
> >   * @vsub: Vertical chroma subsampling factor
> >   */
> > @@ -46,6 +53,8 @@ struct drm_format_info {
> >  	u8 num_planes;
> >  	u8 cpp[3];
> >  	u8 bpp[3];
> > +	u8 ppm[3];
> > +	u8 bpm[3];
> >  	u8 hsub;
> >  	u8 vsub;
> >  };
> > -- 
> > 2.7.4
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux