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

[Rob Clark]

On Wed, May 17, 2017 at 8:38 PM, Rob Clark <robdclark at gmail.com> wrote:
> 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..
>

and by "we've" I really mean Ben plus irc and/or list bikeshedding
from daniels and myself and various others..

BR,
-R