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

[Jesse Barnes <jbarnes@virtuousgeek.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2679 bytes --]

On Tue, 15 Nov 2011 00:37:47 +0200
Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:

> 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 ;)

Ok, added, see the latest patchset.

Dave, please pound the gavel on this now and declare it sold before
someone asks me to add braille support. :)

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel