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