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

[Rob Clark]

On Wed, May 17, 2017 at 8:00 PM, Ben Widawsky <ben at bwidawsk.net> wrote:
> 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.
>

well, maybe don't confuse uabi and what can be represented in a 'C' struct..

we've designed the blob layout w/ uabi in mind (ie. w/ offsets to the
different sections, etc).. doesn't necessarily mean it is something
representable as a 'C' struct.. but it's still a form of uabi..

BR,
-R