[PATCH weston 7/8] compositor-drm: Implement clone mode, refactor output into logical ones

[Daniel Stone]

Hi Pekka,

On 22 November 2016 at 08:54, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Mon, 21 Nov 2016 19:41:33 +0000 Daniel Stone <daniel at fooishbar.org> wrote:
>> On 2 May 2016 at 22:40, Emmanuel Gil Peyrot <emmanuel.peyrot at collabora.com> wrote:
>> The core already has to deal with surfaces overlapping multiple 'real'
>> outputs - i.e. running on different paint cycles - today, so I don't
>> see that punting clones running on disjoint CRTCs makes that problem
>> worse in terms of complexity for the core. We could certainly do
>> better with repaint-cycle time reporting[1] in the core, but just
>> punting down to the backend only makes that worse rather than better,
>> I think.
>
> about the surface/output overlap here... we certainly do handle a
> surface overlapping several disjoint outputs, but I still have not
> convinced myself that we handle mutually overlapping outputs properly.
>
> Why do I say that? Because struct weston_plane has a member called
> 'damage', and drm_output_render() directly subtracts damage from the
> primary plane. Pretty much every backend does that.

Thanks for this - it's a good point. It's strengthened my resolve a
little bit though, especially in the context of
https://phabricator.freedesktop.org/T7621, where our problem is that
repaint is inseparable from, and damaging[0] to, core state. If we
pulled primary_plane out of core, and started calculating repaint data
per-call instead, we could kill two birds with one stone. And also
promote surfaces to planes even if they do span multiple outputs.

Cheers,
Daniel

[0]: Damaging in the sense of buffer damage, i.e. makes changes to.