On Fri, Dec 12, 2014 at 11:14 AM, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> 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@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. 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
