On Wed, May 17, 2017 at 1:31 PM, Daniel Vetter <daniel@xxxxxxxx> 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? Ok, this is the other way round, kernel writes this, userspace reads it. Question still stands. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx