On Fri, Apr 20, 2018 at 10:21:35AM +0300, Tomi Valkeinen wrote: > On 20/04/18 10:00, Daniel Vetter wrote: > > (Adding Benoit back, he was dropped at some point in the thread) > > > Stuff randomly not working is officially how atomic works. That's what the > > TEST_ONLY mode is for. There's a lot more than virtualized planes that > > might or might not push any given plane setup over some random hw limit: > > memory bandwidth, aggregate scaling limits (because not enough fifo), > > thermal limits, aggregate pixel clock limits. There's all kinds of cases > > where with one setup you can light up 4 planes, then move them a bit and > > only 3 work. And yes sometimes that means you can't light up all the > > outputs if you have a too fancy plane config on the other CRTC. > > > > Only userspace which is written with intimate knowledge of the exact > > kernel driver and hw it runs on can avoid TEST_ONLY and some kind of > > fallback strategy to "render everything into the 1 single primary plane". > > Both drm_hwcomposer and weston atomic have such a fallback strategy (with > > various degrees of intermediate cleverness). > > Ok, thanks. This makes sense to me, and actually makes our (driver > developers) life easier... Is "Stuff randomly not working is officially > how atomic works." mentioned in the DRM documentation? I think that > sentence summarizes it quite well =). Hm, I think we fail to doc that properly, at least in-kernel. Improving atomic docs is somewhere on my huge todo list still :-/ The lwn article I've written does explain the motivation behind TEST_ONLY in detail though: https://lwn.net/Articles/653071/ > Does the driver still have some minimal set of functionality it always > has to allow? E.g. is enabling all the available displays with the > display's native resolution (or whatever passes the mode_valid), each > with a single non-scaled full-screen primary plane, something every > driver should ensure is always possible? Strive for, sure. "Always" is a bit much since you easily might run out of clocks (if they all run at different modes), or memmory bandwidth (if there's too many 8k screens) and stuff like that. It's really all best effort. The only guarantee we give for mode_valid is that you should be able to light this mode up if - no other CRTC enabled, - only using the primary plane, - and you tried all the pixel formats of that plane (in case xrbg8888 is too much you might need to try out rgb565, or *shock* C8). I think in practice just trying xrbg8888 should be good enough, since that's what plymouth and other simple generic userspace requires. You're running on some really funky hw if that doesn't work. Yes that guarantee is very minimal, but it's the best we can do really. Historical note aside: The above problem is why atomic's TEST_ONLY also works for modesets, and why atomic does updates across multiple CRTC: Intel's gen7 was the first popular platform that had 3 pipe support but in many situations only allowed to light up 2 outputs, not 3. Userspace died to no end on failed modesets :-/ -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
