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

Pekka Paalanen ppaalanen at gmail.com
Tue Nov 22 09:41:36 UTC 2016

On Tue, 22 Nov 2016 09:06:00 +0000
Daniel Stone <daniel at fooishbar.org> wrote:

> 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.

Indeed, and maybe even allow targeting renderers to arbitrary planes
rather than the hardcoded primary plane. Then we'd "just" need the
planner from hwc2 if it was a good fit...


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20161122/56543db0/attachment.sig>

More information about the wayland-devel mailing list