[PATCH] drm/fourcc: document modifier uniqueness requirements

[Simon Ser]

> > > + * Users see modifiers as opaque tokens they can check for equality and
> > > + * intersect. Users musn't need to know to reason about the modifier value
> > > + * (i.e. users are not expected to extract information out of the modifier).
> > > + *
>
> Doesn't this conflict with "implicit minimal requirements" above?

Ah, when I wrote "users", I meant "non-driver users": programs like
compositors and user-space applications. Of course kernel and user-space
drivers can extract information out of the modifiers. Is this why there's some
confusion here?

> Certainly for a bunch of different AFBC modifiers, the allocator would
> need to understand some fields in order to properly align-up the
> buffer size.

It's probably a little early to speculate on the future allocator design. For
instance, instead of having a monolithic allocator, the kernel driver (and
other buffer consumers) could advertise a list of constraints for each
format/modifier. That way no-one would need to extract information out of
modifiers to figure out alignment (but maybe drivers would still want to, to
reject bad imports for instance). But again, I'm just throwing ideas around at
this point.