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 =). 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? Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki -- 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
