On Mon, 7 Nov 2011 23:55:02 +0900 InKi Dae daeinki@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.