On Mon, Jun 01, 2020 at 11:35:54AM +0100, Brian Starkey wrote:
> On Wed, May 27, 2020 at 10:55:34AM +0200, Daniel Vetter wrote:
> > On Wed, May 27, 2020 at 08:52:00AM +, Simon Ser wrote:
> > > There have suggestions to bake pitch alignment, address alignement,
> > > contiguous memory or other p
> > > + * 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
On Wed, May 27, 2020 at 10:55:34AM +0200, Daniel Vetter wrote:
> On Wed, May 27, 2020 at 08:52:00AM +, Simon Ser wrote:
> > There have suggestions to bake pitch alignment, address alignement,
> > contiguous memory or other placement (hidden VRAM, GTT/BAR, etc)
> > constraints into modifiers. La
On Wed, May 27, 2020 at 08:52:00AM +, Simon Ser wrote:
> There have suggestions to bake pitch alignment, address alignement,
> contiguous memory or other placement (hidden VRAM, GTT/BAR, etc)
> constraints into modifiers. Last time this was brought up it seemed
> like the consensus was to not a
There have suggestions to bake pitch alignment, address alignement,
contiguous memory or other placement (hidden VRAM, GTT/BAR, etc)
constraints into modifiers. Last time this was brought up it seemed
like the consensus was to not allow this. Document this in drm_fourcc.h.
There are several reason
