[PATCH weston v2 1/1] compositor-drm: Unref current & pending fb when deactivating the session

[Miguel Angel Vico]

Indeed. Pekka's fix is equivalent. I missed that.

Thank you.

On Fri, 11 Aug 2017 10:06:28 +0100
Daniel Stone <daniel at fooishbar.org> wrote:

> Hi Miguel,
> 
> On 11 August 2017 at 00:55, Miguel A. Vico <mvicomoya at nvidia.com> wrote:
> > we stopped forcing a modeset when restoring the session. The motivation
> > was that we would use a stale fb, so better to let the next repaint
> > handle it.
> >
> > However, if drm_output::fb_current != NULL, we won't issue a modeset
> > upon repaint.
> >
> > This change unreferences both drm_output::fb_current and
> > drm_output::fb_pending when deactivating the current session. This
> > ensures the very first repaint after restoring the session will issue a
> > modeset.  
> 
> Sorry for missing this the first time around. But I think this fix
> from Pekka should be equivalent:
> 
> commit 6b65d8f12021d8fff0db37fd10b9a469769178b2
> Refs: 2.99.92-4-g6b65d8f1
> Author:     Pekka Paalanen <pekka.paalanen at collabora.co.uk>
> AuthorDate: Thu Jul 27 13:44:32 2017 +0300
> 
>     compositor-drm: reset KMS state on VT-switch in
> 
>     Fix a regression with VT-switching away from Weston and then back
>     causing drmModePageFlip() to fail with ENOSPC or EINVAL, leaving one or
>     more outputs not updated. The regression appeared in
>     47224cc9312fef05c1a523ea0da0a1aae66f100d:
> 
>             compositor-drm: Delete drm_backend_set_modes
> 
>     Fix it by forcing a drmModeSetCrtc() on all outputs both initially
>     created and after VT-switch in.
> 
> Do you still see VT-switching issues?
> 
> Cheers,
> Daniel
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel


-- 
Miguel