Hi, On 9 December 2016 at 19:58, Daniel Stone <dan...@fooishbar.org> wrote: > This is v2 of the atomic patchset, which incorporates quite a few > fixups on the original code, and extends it far enough to flip > sprites_are_broken off for atomic. \o/
And it lives here: git://git.collabora.com/git/user/daniels/weston#wip/phab/T7595-atomic-modeset > First we try to construct a view made entirely out of planes and > nothing else; if this succeeds, we just use that and we don't need to > render anything. Failing that, we try to incrementally build a state, > trying one view at a time on one plane at a time, and seeing if that > changes anything. Doing this is what lets us flip sprites_are_broken, > because we can not only generate an optimal configuration, but make > sure it'll actually work when we do it. There are a couple of things I'm not entirely happy with here in hindsight, that a nice long walk has helped clarify. The duplicate_renderer dance in drm_output_propose_state / drm_output_prepare_scanout_view is messy, and in fact leaks the old state when we successfully promote a view to scanout. I did play around with special-casing the drm_plane_state_*() API to deal with this, but didn't like the non-obviousness it introduced. I think a cleaner solution might just be to duplicate the entire output_state; I'll have another play around with both (and a clearer head) next week. The 'test plane states' commit is obscured by the fact overlay assignment moves from picking one plane early and sticking to that, to testing all the planes in a loop. I was trying to avoid exploding the series into too many patches, but may have got the balance wrong there. I'll probably change that in the next iteration. I think we also need to delay start_repaint_loop() if we have a DPMS off that hasn't completed; in testing just now I was able to hit a rare breakage (hooray for asserts!) which I suspect was exactly this. Short of this, any general commments welcome, as well as review of the earlier patches in the series (thanks Armin!), so we can start landing the less dangerous/controversial pieces and trim the series down a bit. Testing on exotic platforms is always good too: I have Intel, Rockchip (with the Mali driver), and Raspberry Pi (less interesting as it can't put client surfaces in planes) here, and hopefully will have Freedreno running next week. Maybe Tegra if Alexandre posts a tree with that working too. Cheers, Daniel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
