[PATCH v15 02/34] compositor-drm: Disable unused CRTCs/connectors

Pekka Paalanen ppaalanen at gmail.com
Tue Feb 6 11:10:05 UTC 2018

On Mon,  5 Feb 2018 18:44:11 +0000
Daniel Stone <daniels at collabora.com> wrote:

> If we have an unused CRTC or connector, explicitly disable it during the
> end of the repaint cycle, or when we get VT-switched back in.
> This commit moves state_invalid from an output property to a backend
> property, as the unused CRTCs or connectors are likely not tracked by
> drm_outputs. This matches the mechanics of later commits, where we move
> to a global repaint-flush hook, applying the state for all outputs in
> one go.
> The output state_invalid flag originally provoked full changes on output
> creation (via setting the flag at output enable time) and session enter.
> For the new-output case, we will not have any FB in output->state_cur,
> so we still take the same path in repaint as if state_invalid were set.
> At session enter, we preserve the existing behaviour: as
> start_repaint_loop will fail when state_invalid is set, all outputs will
> be scheduled for repaint together, and state_invalid will not be cleared
> until after all outputs have been repainted, inside repaint_flush.
> Signed-off-by: Daniel Stone <daniels at collabora.com>
> ---
>  libweston/compositor-drm.c | 34 +++++++++++++++++++++-------------
>  1 file changed, 21 insertions(+), 13 deletions(-)

Reviewed-by: Pekka Paalanen <pekka.paalanen at collabora.co.uk>

This seems to be the turning point, where outputs not explicitly
disabled will get CRTCs turned off anyway rather than left lingering
with whatever state they were in.

I checked the documentation of weston_output_disable() and I think it
does not need an immediate fix, so all good.

-------------- 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/20180206/9b1ac6ad/attachment.sig>

More information about the wayland-devel mailing list