On Thu, 8 Apr 2021 17:39:22 +0300
Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:

> On Thu, Apr 08, 2021 at 04:57:51PM +0300, Pekka Paalanen wrote:
> > On Thu, 8 Apr 2021 13:30:16 +0200
> > Daniel Vetter <daniel@ffwll.ch> wrote:
> >   

> > > > Is it also so that passing MOD_INVALID to the explicit modifier uAPI
> > > > (ADDFB2) is invalid argument? Do we have that documented?    
> > > 
> > > We'd need to check that, currently it's an out-of-band flag in the struct.
> > > Atm DRM_FORMAT_MOD_INVALID is entirely an internal sentinel value to
> > > denote end-of-array entries.
> > > 
> > > In practice it wont pass because we validate the modifiers against the
> > > advertised list.  
> 
> We don't actually. If the driver provides the .format_mod_supported()
> hook then it's up to the driver to validate the modifier in said hook.
> This was done so that people can embed metadata inside the modifier
> while only having the base modifier on the modifier list. How userspace
> is supposed to figure out which values for this extra metadata are valid
> I have no idea.

Maybe it's the difference between generic userspace and userspace
drivers? I've been having the feeling that these two have different
"rules". Maybe that distinction should be formalised in documentation
somewhere?

Generic userspace never looks into modifiers, it just relays them and
compares them as opaque 64-bit words.

Userspace drivers are allowed to look into what a modifier actually
means and fiddle with it.


Thanks,
pq