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

[Rob Clark]

On Mon, Nov 7, 2011 at 10:12 AM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> 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.?

yes, mainly for planar formats packed in a single buffer object..  But
then planar formats in multiple buffer objects, you'd also need
potentially a pitch for each bo, so I guess that is sort of the same
thing.

In practice, maybe it only matters for 3-plane formats like I420...
2-plane formats like NV12 with U/V interleaved end up having the same
width in the chroma plane as luma, and so (at least in all the cases I
have seen) they have the same pitch.  Still, I420 is a common format,
so makes sense to leave enough information in the interface for this
to work.

BR,
-R

> 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
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>