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@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. 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
