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@xxxxxxxxxxxxxxx> 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. 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. -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
