Hi, On 02/05/2015 10:06 PM, Daniel Vetter wrote: > On Thu, Feb 05, 2015 at 12:48:07PM +0000, Daniel Stone wrote: >> Hi, >> >> On 5 February 2015 at 12:26, Rob Clark <robdcl...@gmail.com> wrote: >>> On Thu, Feb 5, 2015 at 4:15 AM, Daniel Vetter <dan...@ffwll.ch> wrote: >>>> Yeah I noticed the zpos fun when hacking around too. Exynos should >>>> probably switch defaults so that overlays are visible by default. And we >>>> need to standardize the zpos property so that other drivers can use it >>>> too. >>> >>> jfyi, I have a bit of logic in mdp5_crtc_atomic_check() (and really >>> mdp4 probably needs the same) to sort attached planes and derive the >>> actual hw zpos (with each layer having a unique zpos).. >>> >>> I suspect most hw will end up needing the same (ie. dislike having two >>> overlays at same zpos), so might not be a horrible idea to make the >>> atomic helpers do this sorting for us.. > > Oh yeah such a helper would be nice. Especially since on intel hw flipping > planes around means fishing the right value out of some enum table ;-) > So some sort of helper to compute the absolute ordering in a stable way > would be nice. > >> Same with Exynos, except it's a bit funnier still. In terms of its >> hardware, each CRTC has a number of planes which have a fixed zpos. >> The reason exynos_drm exposes zpos is because it sets up a fixed >> number of planes for the entire device and declares they can run >> across every single CRTC, and then works out from the combination of >> CRTC assignment and zpos property, which hardware plane to assign it >> to. This includes the primary, so if you accidentally get zpos==0 in >> there, then you smash the primary plane. Or set a duplicate zpos and >> then the last one in wins. >> >> It also means if you're using multiple CRTCs (e.g. FIMD for internal >> panel plus mixer for external HDMI), then you can only use 5 planes in >> total, rather than 5 planes per head. (And let's not forget that each >> backend has disjoint format support, so again the driver just lies to >> you and claims to support them all, with a silent fallback via a >> default case statement when the format isn't actually supported. >> Whoops.) >> >> I think a more ideal setup would be a much more direct 1:1 mapping >> with the hardware, where each actual plane on each actual CRTC gets >> exposed directly to userspace, perhaps with a fixed/read-only zpos >> property to tell the userspace which plane it's actually configuring. >> I suspect this would be a pretty good map to other hardware as well. > > Hm that sounds indeed a bit funny. I agree that exynos should split planes > into per-crtc and separate the code and capability tables out so that > there's less lying. And zpos should probably be converted to a read-only > property to tell userspace about the facts, instead of doing something > funny behind the scenes.
I agree, it seems be time to convert each planes have unique zpos. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
