On Mon, Nov 14, 2011 at 01:35:57PM -0800, Jesse Barnes wrote:
On Mon, 14 Nov 2011 23:24:55 +0200 Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Mon, Nov 14, 2011 at 12:21:55PM -0800, Jesse Barnes 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 up to 4* buffer objects 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 handles[4];
- __u32 pitches[4]; /* pitch for each plane */
- __u32 offsets[4]; /* offset of each plane */
+};
Hey, what about those interlaced buffers? We talked privately about adding a '__u32 flags' member to both drm_mode_fb_cmd2 and drm_mode_set_plane.
We could stick something like these to those flags: fb_cmd2.flags: #define DRM_MODE_FB_INTERLACED 0x1
set_plane.flags: #define DRM_MODE_PRESENT_TOP_FIELD 0x1 #define DRM_MODE_PRESENT_BOTTOM_FIELD 0x2
Oh sorry I lost track of the internal discussion.
Are those attributes of the fb or of each object? E.g. could you mix interlaced and non-interlaced buffers in a planar format?
I suppose it might be possible that you'd want to treat luma as interlaced and chroma as progressive under some circumstances. But I can't see why simply defining another flag for that wouldn't be enough.
Maybe I need to rename this ioctl to addfb_swissarmyknife :)
Now I'm just waiting for someone to jump in and say that they want independent buffers for each interlaced field :)
Me? I'll be happy with just those two flags members... for now at least ;)