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

[Rob Clark]

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.

> 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.

BR,
-R

> --
> Ville Syrjälä
> Intel OTC