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

[Daniel Vetter]

On Fri, Dec 12, 2014 at 12:05:41PM -0500, Rob Clark wrote:
> On Fri, Dec 12, 2014 at 11:14 AM, Ville Syrjälä
> <ville.syrjala at linux.intel.com> wrote:
> > On Fri, Dec 12, 2014 at 11:00:29AM -0500, Rob Clark wrote:
> >> On Fri, Dec 12, 2014 at 10:30 AM, Ville Syrjälä
> >> <ville.syrjala at linux.intel.com> wrote:
> >> >>
> >> >> Having them separated is still kinda nice though, for the same rationale as
> >> >> the EGLImage import extension having them as hints. If your hardware
> >> >> doesn't support the tiling/compression format you use, then you're going to
> >> >> be showing absolute garbage. But if it doesn't support your exact
> >> >> chroma-siting or YUV range request, it'll still be totally viewable, just
> >> >> not entirely perfect. So I don't see the logic in failing these.
> >> >
> >> > Well, it will look nasty when switching between GL and display
> >> > composition the GL path does the right thing an display path doesn't/
> >> > And we already have that problem with the fuzzy alignment/scaling
> >> > restriction stuff. So I think we will want some kind of strict flag
> >> > somewhere to allow the user to specify that they'd rather fail the whole
> >> > thing and fall back to GL rather than annoy the user.
> >>
> >>
> >> another argument in favor of plane properties, I think.  This way
> >> userspace can query what is actually possibly and we don't implicitly
> >> give userspace the idea that display hw can handle something that it
> >> doesn't..
> >
> > Well, we don't have properties to describe a lot of the limitations. I'm
> > not sure we want to add tons of read-only properties for that. And as
> > stated, sometimes the limitations depend on other properties/pixel
> > format/etc. so seems rather hard to describe in a sane way that would
> > actually be useful to userspace.
> 
> sorry, wasn't quite what I meant..  What I meant was that YUV range
> and siting properties would probably be enum properties, so userspace
> could see which enum values are supported.
> 
> r/o props could be a way to deal w/ some limits.  Other limits, it
> could just be a matter of expressing the correct range as we convert
> things to properties for atomic.

There's still the problem that yuv setting might not work on all formats,
maybe it only works on the planar ones.

> > One idea that came up again just yesterday would be to have the kernel
> > assign the planes on behalf of userspace. But that would then mean we
> > need some kind of virtual plane layer on top so that the virtual plane
> > state gets tracked correctly, or userspace would need to pass in the
> > entire state for every display update. Also soon it may start to look
> > like we're implementing some kind of compositor in the kernel. Another
> > other approach might be to implement this plane assignment stuff in
> > libdrm and duplicate some hw specific knowledge there.
> 
> I kinda lean towards userspace.  I don't want to preclude the case of
> a smart userspace (which has some driver specific userspace piece)..
> could be an interesting idea to have something in libdrm.

I expect this to happen sooner or later, probably a descendant of hwc (with
all the assumtpions about single-crtc fixed and maybe some provisions to
allow flips faster than vblanks).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch