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

[Ben Widawsky]

On 17-05-17 13:31:44, Daniel Vetter wrote:
>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

The API says there is a blob. If we wanted the fields in the blob to be explicit
we'd make an API that has the exact structure.

-- 
Ben Widawsky, Intel Open Source Technology Center