On Mon, Nov 7, 2011 at 10:12 AM, Jesse Barnes <jbar...@virtuousgeek.org> wrote:
> On Mon, 7 Nov 2011 23:55:02 +0900
> InKi Dae <daei...@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@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
