[PATCH weston v2 0/68] Atomic modesetting, planes, extended drm_fb

[Daniel Stone]

Hi,

On 9 December 2016 at 19:58, Daniel Stone <daniel at 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