On Mon, 7 Nov 2011 23:55:02 +0900
InKi Dae <daeinki@xxxxxxxxx> wrote:
> > +struct drm_mode_fb_cmd2 {
> > + __u32 fb_id;
> > + __u32 width, height;
> > + __u32 pixel_format; /* fourcc code from videodev2.h */
> > +
> > + /*
> > + * In case of planar formats, this ioctl allows one
> > + * buffer object with offets and pitches per plane.
> > + * The pitch and offset order is dictated by the fourcc,
> > + * e.g. NV12 (http://fourcc.org/yuv.php#NV12) is described as:
> > + *
> > + * YUV 4:2:0 image with a plane of 8 bit Y samples
> > + * followed by an interleaved U/V plane containing
> > + * 8 bit 2x2 subsampled colour difference samples.
> > + *
> > + * So it would consist of Y as offset[0] and UV as
> > + * offeset[1]. Note that offset[0] will generally
> > + * be 0.
> > + */
> > + __u32 handle;
> > + __u32 pitches[4]; /* pitch for each plane */
> > + __u32 offsets[4]; /* offset of each plane */
> > +};
>
> I think that it doesn't pitches[] and offsets[] because we can
> calulate pitch and offset per plane in kernel side through pixel
> format information from user. (PS. pixel format has unique value) I
> think it's good to remove them if unnecessary. there could be my
> missing point. so Rob, could you please tell me about why do you need
> them.?
Daniel seemed to think that some of the formats might have ambiguous
pitches or offsets, so being able to specify one for each possible
component seems like a good idea.
Also, for planar formats packed into a single buffer object handle
(through driver specific multiplexing or non-zero offsets), individual
pitches and offsets may be required.
--
Jesse Barnes, Intel Open Source Technology Center
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
