[RFC] drm: add support for tiled/compressed/etc modifier in addfb2

[Daniel Vetter]

On Fri, Dec 12, 2014 at 10:56:21AM -0500, Rob Clark wrote:
> On Fri, Dec 12, 2014 at 10:11 AM, Daniel Stone <daniel at fooishbar.org> wrote:
> > Hi,
> >
> > On 12 December 2014 at 14:56, Ville Syrjälä <ville.syrjala at linux.intel.com>
> > wrote:
> >>
> >> On Fri, Dec 12, 2014 at 08:50:18AM -0500, Rob Clark wrote:
> >>
> >> > It does make me briefly think of just letting us set properties on fb
> >>
> >> > objects :-P (but maybe that is a bit overkill)
> >>
> >> Yeah I had the same idea at some point. But then I decided that we could
> >> just have these as properties on the plane.
> >
> >
> > Mm, it does seem a bit weird. Yes, they are relative to how the plane
> > interprets things, but then again so is the format surely. Not to mention
> > another thing to go wrong, if someone forgets to set and/or clear it when
> > changing the plane. Keeping it in the fb eliminates that possibility.
> >
> 
> yeah.. logically it seems nicer for them to be prop's on fb's.  The
> drawback is having to invent some bit of infrastructure to support
> that.  Avoidance of inheriting someone else's plane prop's might be
> enough justification to invent that infrastructure.  But fb prop's
> don't really help w/ the whole not-all-planes-are-the-same thing..

The nice thing with fbs currently is that all the metadata is invariant.
Imo we should keep that for any prop extension, since it massively
simplifies things for everyone.

But I'm not sure that's so important since we already have (and probably
always will have) a mess between plane and fb props. E.g. the rotation
thing actually affects the pte ordering on skl. So would be nice to have
as an invariant fb prop, but since it's now on the plane we can't change
it.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch