Indeed. Pekka's fix is equivalent. I missed that. Thank you.
On Fri, 11 Aug 2017 10:06:28 +0100 Daniel Stone <dan...@fooishbar.org> wrote: > Hi Miguel, > > On 11 August 2017 at 00:55, Miguel A. Vico <mvicom...@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.paala...@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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Miguel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel