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
