[PATCH 2/5] drm: add an fb creation ioctl that takes a pixel format

Jesse Barnes jbarnes at virtuousgeek.org
Mon Nov 7 08:12:45 PST 2011


On Mon, 7 Nov 2011 23:55:02 +0900
InKi Dae <daeinki at gmail.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111107/34988b98/attachment.pgp>


More information about the dri-devel mailing list