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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
