<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - weston-launch does not restore the interface" href="https://bugs.freedesktop.org/show_bug.cgi?id=106179#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - weston-launch does not restore the interface" href="https://bugs.freedesktop.org/show_bug.cgi?id=106179">bug 106179</a> from <a class="email" href="mailto:ppaalanen@gmail.com" title="Pekka Paalanen <ppaalanen@gmail.com>"> Pekka Paalanen</a> <pre>Thank you. It's a little bit along the lines I suspected, but in a surprising way. The below is my analysis for the record: Main details from the log: - atomic modesetting is in use The interesting sequence: [07:07:31.718] activating session ... [07:07:31.797] DRM: expected property DPMS to not be an enum, but it is; ignoring [07:07:31.797] DRM: expected property DPMS to not be an enum, but it is; ignoring [07:07:31.817] unexpectedly large timestamp jump (from 31925138 to 31934769) [07:13:57.726] atomic: couldn't commit new state: Permission denied [07:13:57.727] deactivating session Judging by the timestamps, it seems that EPERM might result from a sequence like this: - user hits Ctrl+Alt+F# - that ends up calling launcher_logind_activate_vt() - logind revokes DRM access - libweston core hits repaint and fails atomic flip with EPERM - logind signals VT deactivation - session_notify() gets called, prints "deactivating session" If an atomic flip fails, I think libweston will never try again, which leads to no screen updates. Looks like two things: fix the race (libweston or logind?), and maybe find a way to recover from atomic failures.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>