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

[Marius-cristian Vlad]

-----Original Message-----
From: Pekka Paalanen [mailto:pekka.paalanen at collabora.co.uk] 
Sent: Thursday, January 25, 2018 2:06 PM
To: Daniel Stone <daniel at fooishbar.org>
Cc: Marius-cristian Vlad <marius-cristian.vlad at nxp.com>; Keith Packard <keithp at keithp.com>; wayland-devel at lists.freedesktop.org
Subject: Re: [PATCH weston] RFC: libweston/compositor-drm: Add support for drm-lease.

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?

[mvlad] I would assume that a client will detroy its fb and, afterwards will revoke the lease. You won't be able the access the leased fd after revoking it. Weston will not be unable to repaint anything if there's currently no ouput to repaint on. I hope I understand your question correctly :/.  

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?

[mvlad] Yes that is correct. RMFB will lead the CRTC and connector to be turned off. If there's no FB present the helpers in DRM atomic commit part will disable that CRTC.  

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?

[mvlad] There seems to be no flicker when destroying the output with drm_output_destroy. This is rather blunt, but that's what I see happening. 

What about leaking fb contents between the lessor and lessee?

[mvlad] The client has its own fbs. What could happen is that the ouput "shared" by lessor/lessee can have inter-leaved fbs if the
lesor is still using the output, but I see that happening only on purpose. 

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?

[mvlad] Yes on every "contract" the CRTC will go thru that on/off stage. As long as weston is no longer using/owning that output (connector) I don't see how that's possible. How can it "take" more resources if it is not aware of that connector? Right?  


Thanks,
pq