On Tue, May 03, 2016 at 09:08:06AM +0300, Tomi Valkeinen wrote:
>
> On 03/05/16 00:01, Rob Clark wrote:
> > On Mon, May 2, 2016 at 11:43 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote:
> >> Hi Laurent,
> >>
> >> On 26/04/16 23:35, Laurent Pinchart wrote:
> >>> The number of bits per pixel is identical for all planes, don't store
> >>> multiple copies.
> >>
> >> That's not true, as with NV12, Y has 8 bits per pixel and UV has 16 bits
> >> per pixel. But as the subsampling is precalculated into the stride_bpp
> >> (is it bytes or bits? bpp always confuses me =), the 'stride_bpp' ends
> >> up being same for both planes.
> >>
> >> To be honest, I'd rather go into more complex struct than simpler one.
> >> The current one is already confusing, I think, and your version is too.
> >> The main issue is that the sub_x is encoded into the stride_bpp. In
> >> kmsxx I used this format:
> >>
> >> { PixelFormat::NV12, { 2, { { 8, 1, 1, }, { 8, 2, 2 } }, } },
> >>
> >> The first number is the number of planes, and for each plane, bitspp,
> >> xsub and ysub. It's more verbose, but (I think) easier to understand.
> >
> > fwiw, I guess a lot of data from that table could these days be
> > replaced w/ some of the drm format helpers
> > (drm_format_num_planes()/drm_format_plane_cpp()/drm_format_{horz,vert}_chroma_subsampling()/etc)
>
> Indeed, I think we can remove all but the DRM -> DSS format mapping.
>
> Btw, what is "cpp" short from?
Bytes per pixel. The 'c' is silent :P
PS.
Actually it's "chars per pixel"
--
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
