[PATCH weston 1/9] compositor-drm: drm_output_enable updates unused_crtcs/connectors

[Pekka Paalanen]

On Mon, 12 Feb 2018 12:26:50 +0000
Daniel Stone <daniel at fooishbar.org> wrote:

> Hi Pekka,
> 
> On 9 February 2018 at 13:07, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > Let drm_output_enable() remove the CRTC and the connector from the
> > unused id arrays.
> >
> > In the future when a list of drm_heads supersedes unused_connectors
> > array, the usedness of a connector will be determined by the enabled
> > state of the output the connector (head) is attached to. The enabled
> > state is turned on by drm_output_enable(). If unused_crtcs array was
> > still updated in drm_output_repaint(), the CRTC and connector usedness
> > would be tracked in different places. Logically the two belong together.  
> 
> I agree that when we have heads/connectors, this is logically the
> right thing to do. This patch does reflexively make me a little uneasy
> though: it relies on the repaint loop successfully completing before
> the next repaint flush. The reason I moved the unused ID removal to
> the bottom of repaint, is because that's the first point at which we
> know (within reason) that repaint will succeed.

This patch is not essential for this series, so we could just leave it
with the actual DRM-backend migration to head-based API.

In IRC you and Derek discussed about landing the clone mode series up
to the point I sent v5, but that does not include the DRM-backend
changes. If we landed this patch and the equivalent of the v5 series,
then the next release would not have DRM-backend changes that make use
of this patch.

> On the other hand, if repaint fails the output pretty much just wedges
> forever anyway. So even though I'm kind of wary of this first one and
> get the feeling we might end up revisiting it, I don't think it makes
> things worse, and hopefully clone-mode makes it completely obsolete
> anyway.

Right. The DRM-backend changes in the clone mode series do not improve
fault tolerance either. The public head-based API has opportunities for
a backend to return failure, but it relies on synchronous checks, so we
cannot really check much.

Being able to relay and cope with an async output failure is still on
the drawing board.

> Bar a couple of minor nitpicks, series is:
> Reviewed-by: Daniel Stone <daniels at collabora.com>

Cool, thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180212/464cc754/attachment.sig>