Comment 81 for bug 604635

(In reply to Justin Lebar [:jlebar] from comment #48)
> > Are you saying that there should only be one application given screen-management permissions?
>
> No. I don't want our architecture here to force Gaia/Gaia-alternative
> developers to implement their front-end in any particular way.
>

Agreed!

> > An idle notification sounds like a generally useful thing. Has anyone proposed this before? It
> > sounds easy to spec and implement.
>
> I talked with people about this at the last work-week, but I don't know if
> you were there. I'd like to design the API only once we have a consumer,
> though. So once the front-end people are ready for it, we can design it.
> (For example, it might make sense to register a callback which says "notify
> me when the device has been idle for X seconds, or when there are no more
> wake locks with topic T held, whichever comes last.")
>

I think we're ready for it now :). I'll file.

> screen.{brightness,enabled} are low-level functions, and at least the
> screen/brightness wakelocks are advisory to the screen management code. The
> screen code is free to ignore the wake locks and enable/disable/dim the
> screen at will. Otherwise, it can't turn off the screen when the user
> presses the power button!
>

That's the point of wake locks, to prevent the screen from being turned off. We need to specify which one "wins". I think it makes more sense for wake locks to "win", since a conformant (privileged) user of screen.enabled wouldn't try to turn off the screen if there are wake locks, anyway. Or at least, wouldn't expect it to turn off.

> Even for functionality whose wake-locks interact with the kernel, we're
> still going to need a way for the power manager to hard-disable it. For
> example, when you go into airplane mode, we have to turn off the 3G radio,
> even if a 3G wake lock is held.

How does that work in android? If wake locks "win" generally, then what we can do on trying to enter airplane mode is a set a timeout on apps that hold the locks, and kill them if they don't let go soon enough. It might also make sense to build in functionality to wake locks to notify holders when a drop is urgent or pending. Then conforming apps can let go of their locks and stay alive.