[Intel-gfx] [PATCH 2/3] drm: Create a format/modifier blob

Daniel Vetter daniel at ffwll.ch
Wed May 17 11:31:44 UTC 2017


On Tue, May 16, 2017 at 02:19:12PM -0700, Ben Widawsky wrote:
> On 17-05-03 17:08:27, Daniel Vetter wrote:
> > On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
> > > +struct drm_format_modifier_blob {
> > > +#define FORMAT_BLOB_CURRENT 1
> > > +	/* Version of this blob format */
> > > +	u32 version;
> > > +
> > > +	/* Flags */
> > > +	u32 flags;
> > > +
> > > +	/* Number of fourcc formats supported */
> > > +	u32 count_formats;
> > > +
> > > +	/* Where in this blob the formats exist (in bytes) */
> > > +	u32 formats_offset;
> > > +
> > > +	/* Number of drm_format_modifiers */
> > > +	u32 count_modifiers;
> > > +
> > > +	/* Where in this blob the modifiers exist (in bytes) */
> > > +	u32 modifiers_offset;
> > > +
> > > +	/* u32 formats[] */
> > > +	/* struct drm_format_modifier modifiers[] */
> > > +} __packed;
> > 
> > The struct should be in the uapi header. Otherwise it won't show up in
> > libdrm headers when following the proper process.
> > -Daniel
> > 
> 
> I don't agree that blobs are ever really part of the API, but it doesn't hurt to
> move it... in other words, done.

Userspace writes them, the kernel reads them (or maybe even the other way
round). How exactly is a specific blob and its layout not part of uapi?
Can you explain your reasoning here pls?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the Intel-gfx mailing list