Subject: Fwd: Screen Blanking Power Management Requirements

From: Robert Carr <[email-masked]>
Date: Mon, 24 Jun 2013 10:29:55 -0700

Hi! There was a meeting today on power management requirements for Mir on
phablet. Sending out an email to capture the new requirements.

Essentially the model is as follows:

The shell will use it's event filter, to emit DBus events, i.e. Session
Idle (say no input in X minutes), Session Unidle.

powerd will listen to these events and combine power management policy
(i.e. do we blank the screen on idle? perhaps there is a video playing, so
we do not at the moment), and in many cases ask the shell again "blank".

So the requirement on Mir is for methods on mg::Display to blank/unblank
the display. Is someone able to take this as a work item?

Thanks,
Robert

---

From: Kevin DuBois <[email-masked]>
Date: Mon, 24 Jun 2013 15:03:43 -0700

I added myself for this requirement here (kgunn/robert_ancell, please move
task if there's a better place):
https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-phone

The approach sounds sensible. The event should come from somewhere else to
mir.
There is a caveat though, which is that we are not in a good place (from an
architectural position) to control the backlight settings when the screen
turns off. We can pause the mir server and turn the display off easily
enough, but the backlight control should probably be somewhere else.

Cheers,
Kevin

On Mon, Jun 24, 2013 at 10:29 AM, Robert Carr <[email-masked]>wrote:

> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>
>

---

From: Daniel van Vugt <[email-masked]>
Date: Tue, 25 Jun 2013 09:32:16 +0800

If anyone isn't aware yet, you can control a backlight (including on 
Android devices) by writing to:
   /sys/class/backlight/$x/brightness
up to a maximum value of
   /sys/class/backlight/$x/max_brightness

On 25/06/13 06:03, Kevin DuBois wrote:
> I added myself for this requirement here (kgunn/robert_ancell, please
> move task if there's a better place):
> The approach sounds sensible. The event should come from somewhere else
> to mir.
> There is a caveat though, which is that we are not in a good place (from
> an architectural position) to control the backlight settings when the
> screen turns off. We can pause the mir server and turn the display off
> easily enough, but the backlight control should probably be somewhere else.
>
> Cheers,
> Kevin
>
>
>
>
> On Mon, Jun 24, 2013 at 10:29 AM, Robert Carr <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>     Hi! There was a meeting today on power management requirements for
>     Mir on phablet. Sending out an email to capture the new requirements.
>
>     The shell will use it's event filter, to emit DBus events, i.e.
>     Session Idle (say no input in X minutes), Session Unidle.
>
>     powerd will listen to these events and combine power management
>     policy (i.e. do we blank the screen on idle? perhaps there is a
>     video playing, so we do not at the moment), and in many cases ask
>     the shell again "blank".
>
>     So the requirement on Mir is for methods on mg::Display to
>     blank/unblank the display. Is someone able to take this as a work item?
>
>     Thanks,
>     Robert
>
>
>     --
>     Mir-devel mailing list
>     [email-masked] <mailto:[email-masked]>

---

From: Daniel van Vugt <[email-masked]>
Date: Tue, 25 Jun 2013 09:37:37 +0800

I agree. There's not yet been any case I've seen for backlight control 
being part of a display server, _other_ than the problem of device 
permissions.

The regular non-root user does not have permission to write to 
/sys/class/backlight/... so that probably needs to be set up somehow on 
login. Hence it is the display server's problem, a little bit.

Once that's done, the display server should have nothing to do with 
backlight levels. Turning the display on and off (sleeping) should be a 
different operation (which the display server does care about).

---

From: Daniel van Vugt <[email-masked]>
Date: Tue, 25 Jun 2013 10:54:35 +0800

Some of the feature, like the blank/unblank obviously lives inside 
libmirserver. But I think we should also move common logic that won't 
change between shells into libmirserver, such as detection of input 
events to calculate inactivity.

Also, the assertion that input events will trigger dbus messages is 
either a bad interpretation of mine, or just a bad idea. Input events 
easily happen 1000 times per second. You don't want to turn those into a 
flood of bus messages. The timeout has to happen in the Mir server itself.

On 25/06/13 01:29, Robert Carr wrote:
>
>
> Hi! There was a meeting today on power management requirements for Mir
> on phablet. Sending out an email to capture the new requirements.
>
> (i.e. do we blank the screen on idle? perhaps there is a video playing,
> so we do not at the moment), and in many cases ask the shell again "blank".
>

---

From: Robert Carr <[email-masked]>
Date: Tue, 25 Jun 2013 09:39:48 -0700

The shell will use a timer, and send DBus messages like:

session_gone_inactive (no input events in X minutes), activity_resumed (an
input event on an inactive session).

On Mon, Jun 24, 2013 at 7:54 PM, Daniel van Vugt <
[email-masked]> wrote:

> change between shells into libmirserver, such as detection of input events
> to calculate inactivity.
>
> Also, the assertion that input events will trigger dbus messages is either
> a bad interpretation of mine, or just a bad idea. Input events easily
> happen 1000 times per second. You don't want to turn those into a flood of
> bus messages. The timeout has to happen in the Mir server itself.
>
>
>
> Modify settings or unsubscribe at: https://lists.ubuntu.com/**
> mailman/listinfo/mir-devel<https://lists.ubuntu.com/mailman/listinfo/mir-devel>
>

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 26 Jun 2013 09:51:13 +0800

"The shell will use a timer, and send DBus messages like: 
session_gone_inactive (no input events in X minutes), activity_resumed 
(an input event on an inactive session)."

Right, so that just means whenever the user changes their power 
management timeouts, Mir will have to receive a message to be told to 
adjust the timeout it uses. Because Mir's timeout must match whatever 
the user has configured for their screensaver.

But then for Mir to send any message saying "I've timed out now, please 
give me permission to blank" is pointless. Because Mir already has all 
the timeout logic, and it already has all the logic for doing the 
blanking. No external daemons need to be notified except perhaps that 
"The screen has been blanked".

Mir doesn't need to ask for permission to blank the screen. It just 
needs to receive config changes to know what the screensaver timeout is.

On 26/06/13 00:39, Robert Carr wrote:
> session_gone_inactive (no input events in X minutes), activity_resumed
> (an input event on an inactive session).
>
>
> On Mon, Jun 24, 2013 at 7:54 PM, Daniel van Vugt
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     libmirserver. But I think we should also move common logic that
>     won't change between shells into libmirserver, such as detection of
>     input events to calculate inactivity.
>
>     either a bad interpretation of mine, or just a bad idea. Input
>     events easily happen 1000 times per second. You don't want to turn
>     those into a flood of bus messages. The timeout has to happen in the
>     Mir server itself.
>
>
>
>         Session
>         policy
>         blank/unblank
>     https://lists.ubuntu.com/__mailman/listinfo/mir-devel
>     <https://lists.ubuntu.com/mailman/listinfo/mir-devel>
>
>

---

From: Robert Carr <[email-masked]>
Date: Tue, 25 Jun 2013 21:25:54 -0700

Right now, upower is used as a point for policy, i.e. "a video is playing
so we will not actually blank the screen". It's possible these interfaces
should be rewired, and the media players should instead talk to the shell,
or some other desktop service, but this isn't our problem :) Mir just needs
to expose the API on the display to implement the policy, everything else
(IPC, configuration... included) lives at the shell level.

On Tue, Jun 25, 2013 at 6:51 PM, Daniel van Vugt <
[email-masked]> wrote:

> input event on an inactive session)."
>
> Right, so that just means whenever the user changes their power management
> timeouts, Mir will have to receive a message to be told to adjust the
> timeout it uses. Because Mir's timeout must match whatever the user has
> configured for their screensaver.
>
> give me permission to blank" is pointless. Because Mir already has all the
> timeout logic, and it already has all the logic for doing the blanking. No
> external daemons need to be notified except perhaps that "The screen has
> been blanked".
>
> Mir doesn't need to ask for permission to blank the screen. It just needs
> to receive config changes to know what the screensaver timeout is.
>
>
>
>> <[email-masked] <mailto:daniel.van.vugt@**canonical.com<[email-masked]>
>> >>
>>
>> wrote:
>>
>>     [email-masked] <mailto:Mir-devel@lists.**ubuntu.com<[email-masked]>
>> >
>>
>>     https://lists.ubuntu.com/__**mailman/listinfo/mir-devel<https://lists.ubuntu.com/__mailman/listinfo/mir-devel>
>>     <https://lists.ubuntu.com/**mailman/listinfo/mir-devel<https://lists.ubuntu.com/mailman/listinfo/mir-devel>
>> >
>>
>>
>>

---

From: Thomas Voß <[email-masked]>
Date: Wed, 26 Jun 2013 07:14:34 +0200

I do agree with Robert here. We want powerd to be our single point of
entry to power-mgmt-policy execution. While this introduces a
roundtrip in the "screen-blank-on-user-idle" scenario, I think the
clear separation between policy and actual implementation to blank the
screen is a real benefit.

HTH,
  Thomas

On Wed, Jun 26, 2013 at 6:25 AM, Robert Carr <[email-masked]> wrote:
> Right now, upower is used as a point for policy, i.e. "a video is playing so
> we will not actually blank the screen". It's possible these interfaces
> On Tue, Jun 25, 2013 at 6:51 PM, Daniel van Vugt
> <[email-masked]> wrote:
>>

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 26 Jun 2013 13:51:59 +0800

Why is it shell-specific? Wouldn't power management behaviour want to be 
much the same in most shells? In which case, it could go in 
libmirserver. And optionally overridable in the shell.

On 26/06/13 12:25, Robert Carr wrote:
> Right now, upower is used as a point for policy, i.e. "a video is
> playing so we will not actually blank the screen". It's possible these
> interfaces should be rewired, and the media players should instead talk
> to the shell, or some other desktop service, but this isn't our problem
> :) Mir just needs to expose the API on the display to implement the
> policy, everything else (IPC, configuration... included) lives at the
> shell level.
>
>
>     session_gone_inactive (no input events in X minutes),
>     activity_resumed (an input event on an inactive session)."
>
>     management timeouts, Mir will have to receive a message to be told
>     to adjust the timeout it uses. Because Mir's timeout must match
>     whatever the user has configured for their screensaver.
>
>     But then for Mir to send any message saying "I've timed out now,
>     please give me permission to blank" is pointless. Because Mir
>     already has all the timeout logic, and it already has all the logic
>     for doing the blanking. No external daemons need to be notified
>     except perhaps that "The screen has been blanked".
>
>         events
>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>
>         wrote:
>
>                  Hi! There was a meeting today on power management
>         requirements
>                  for Mir
>                  (i.e. do we blank the screen on idle? perhaps there is
>         a video
>                  playing,
>                  so we do not at the moment), and in many cases ask the
>         shell
>                  again "blank".
>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>
>
>         https://lists.ubuntu.com/____mailman/listinfo/mir-devel
>         <https://lists.ubuntu.com/__mailman/listinfo/mir-devel>
>              <https://lists.ubuntu.com/__mailman/listinfo/mir-devel
>         <https://lists.ubuntu.com/mailman/listinfo/mir-devel>>
>
>
>