unity8 killed/crash then restart can result in mir unable "could not unblank display"

I get the "Could not unblank display" occasionally on boot (reproduced with build #86), not only when unity8 crashes or is killed. That was reported as bug 1235000 and marked as duplicate of this report.

current thinking is to fix short term by adding to powerd policy logic, a check for unity8 presence - if its hosed, then don't change any state. this would prevent confusion upon the return/restart of unity8, and the subsequent unblank attempt of mir should be fine.

final solution would be to migrate the policy logic out to powerd into unity8 shell (since he has a tops down view of the system/activity) - and make powerd just an executioner of power states (no longer policy owner)

Settings to critical because it occurred on 1rst boot after flashing a mako with build #89

if anyone with privilege could change the priority, that'd be nice :)

OK - please see that this has a intermediary fix to it
https://code.launchpad.net/~ricmm/powerd/suspend-if-mir-alive/+merge/190173

closing this as i've added a blueprint to track feature dev effort of moving power policy from powerd to unity/mir here https://blueprints.launchpad.net/ubuntu/+spec/client-1404-unity-ui-windowmanager

I don't think this should be marked as Fix Released, kgunn, as it's clearly still an issue - even if there's a blueprint workitem, this bug should be marked Triaged, and linked to the blueprint.

ok, reopening but with lower priority

is critical/fix released appropriate for mir either? seems this is still open

you're probably right - its band-aided atm

On Thu, Jan 9, 2014 at 10:48 AM, Kevin DuBois <email address hidden>wrote:

> is critical/fix released appropriate for mir either? seems this is still
> open
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1236525
>
> Title:
> unity8 killed/crash then restart can result in mir unable "could not
> unblank display"
>
> Status in Mir:
> Fix Released
> Status in PowerD:
> Triaged
> Status in Unity Mir:
> Triaged
>
> Bug description:
> Note - under normal use of unity/mir this phenomena is not seen (e.g. a
> user will never see it)
> this bug is actually capturing the need for some type of
> re-initialization state of powerd as it relates to the restart of unity &
> mir.
> for instance in the case where the system is under test, the problem is
> that if unity8 is killed (and in contagion mir), powerd may still change
> state independently - which can result in mir both being a) confused about
> the fb state & b) unable/no control to actually change the fb state
>
> possible solutions
> 1) unity-mir needs to somehow reinit powerd into a "good state" for mir
> or 2) mir needs to talk to powerd directly (altho this would mean
> contagious changes needed in mir)
>
> related to this bug
> https://bugs.launchpad.net/mir/+bug/1188504
>
> WORKAROUND:
> stop powerd
>
> associated blueprint for a more complete solution
>
> https://blueprints.launchpad.net/ubuntu/+spec/client-1404-unity-ui-windowmanager
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mir/+bug/1236525/+subscriptions
>

I also agree with kgunn that our policy situation surrounding power is a bit fishy. It seems unity (or the mir demos) sometimes wants to turn powerd on (but we aren't doing so currently).

The bug state looks wrong...

mir: Fix Released but no branch exists (hence no milestone either)
powerd: Triaged but branch already landed

Could someone involved in this bug please correct those?

dashboard was completly busted for build 224.

found that tests throw exception: http://paste.ubuntu.com/7048312/

found that rev 199 in http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/revision/199 tried to change unity8 unlock logic, which refers in the commit message to this bug.

Since this bug didn't seem to have landed I assume it was lack of coordination, hence I will back rev 199 for now hoping that the dashboard goes green.

Please talk to plars.

Small update to this bug - this work is underway to remove some of the display state & policy out of powerd into unity-system-compositor (u-s-c). Powerd will still broadcast the power events, but U-S-C will be the one determining what that means & act as a proxy for any requests wrt screen state from untiy-mir.

Isn't this bug gone basically because of u-s-c anyway? I haven't seen this issue for a long time.

closing as this should be corrected through our recent powerd/u-s-c policy rewrites