[Bug 1623853] Re: Device appears to be off after updating to 15Sept2016's rc-proposed image

[Alexandros Frantzis]

> can you compare what powerd used to do with what repowerd is doing now
in this scenario

Based on jibel's theory from comment #23:

With powerd the timeout logic was in USC, so if USC hasn't started (e.g.
because of apparmor recompilation in this case?) the device won't
suspend.

With repowerd all the timeout logic is in repowerd itself; USC is used
only as a source of events (e.g. power button, touches). In this case,
since repowerd doesn't get any requests to disallow suspending, it
correctly suspends after the normal timeout.

I think a sensible solution would be to disallow suspending until at
least USC (and possibly unity8) is up and running. This could be
achieved by acquiring and releasing a suspend blocker from repowerd at
the init system level, with a prohibit_suspend_at_boot upstart/systemd
job: on "repowerd started" acquire a suspend blocker, on "usc/unity8
started" release the blocker.

Even without the suspend issue, the initial delay after first boot due
to apparmor recompilation or whatnot does not provide a good experience,
since there is no visual indication that something is going on for a
significant amount of time. This brings up the following questions:

0. Why do we need to recompile the profiles at first boot?
1. Could we start USC before the recompilation and other time consuming tasks start, so at least the user would be able to see the dots animating (and incidentally this would also solve the suspend issue)?

-- 
You received this bug notification because you are a member of Ubuntu
Phablet Team, which is subscribed to repowerd in Ubuntu.
https://bugs.launchpad.net/bugs/1623853

Title:
  Device appears to be off after updating to 15Sept2016's rc-proposed
  image

To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1623853/+subscriptions