[PATCH weston] RFC: libweston/compositor-drm: Add support for drm-lease.

[Pekka Paalanen]

On Thu, 25 Jan 2018 11:33:34 +0000
Daniel Stone <daniel at fooishbar.org> wrote:

> Hi Marius,
> 
> On 25 January 2018 at 11:10, Marius-cristian Vlad
> <marius-cristian.vlad at nxp.com> wrote:

> > >> +                       wl_signal_emit(&compositor->wake_signal, compositor);
> > >> +                       wl_event_source_timer_update(compositor->idle_source,
> > >> +
> > >> + compositor->idle_time * 1000);  
> > >
> > > I assume this is just to force a repaint. If the existing
> > > compositor API doesn't quite work for this, we should create API
> > > which does, or make sure enabling the output does the right
> > > thing. Are you using desktop-shell, or ... ?  
> >
> > [mvlad] Indeed. What I've observed is that it could be some time
> > until the repaint fires and in that time the fb of the client can
> > still be present on that output. Forcing a repaint seems to fix
> > that. There's also a longer explanation: If the client destroyes
> > the fb this would cause the connector to be disabled. If weston can
> > reclaim the connector after it has been disabled there's no issue.
> > I will need to check this once more, it might not be needed after
> > all.  
> 
> Right. If we create/enable a new Weston output, this should result in
> repaint happening by itself: just like it does with hotplug now.

Still, should we have the client wait for the compositor to have
actually posted a repaint of the output before the client destroys its
fb?

Do I understand right that the client destroying the fb would cause the
CRTC and connector to be turned off immediately? Do we want to avoid
that flicker if Weston is to take that output back into use?

That brings to my mind the opposite question: if weston stops using an
output so that it can lease it out, how's the flicker avoidance in that
case?

What about leaking fb contents between the lessor and lessee?

I'm kind of guessing that avoiding flicker is out of scope and it may
well happen, and that preventing fb content leaking is more important.
Is that right?

Does this result in toggling the CRTC off and on again on every
hand-over? Given Weston's opportunistical usage of KMS resources, would
it not create a risk of the lessee not being able to turn the CRTC back
on if Weston manages to take more KMS resources (e.g. memory bandwidth
via use of overlay planes) into use first?


Thanks,
pq