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