Fwd: Screen Blanking Power Management Requirements

[Daniel van Vugt]

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.
>
>
> On Tue, Jun 25, 2013 at 6:51 PM, Daniel van Vugt
> <daniel.van.vugt at canonical.com <mailto:daniel.van.vugt at canonical.com>>
> wrote:
>
>     "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:
>
>           >> 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.
>
>         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
>         <daniel.van.vugt at canonical.com
>         <mailto:daniel.van.vugt at canonical.com>
>         <mailto:daniel.van.vugt at __canonical.com
>         <mailto:daniel.van.vugt at canonical.com>>>
>
>         wrote:
>
>              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.
>
>                  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
>
>
>
>
>              --
>              Mir-devel mailing list
>         Mir-devel at lists.ubuntu.com <mailto:Mir-devel at lists.ubuntu.com>
>         <mailto:Mir-devel at lists.__ubuntu.com
>         <mailto:Mir-devel at lists.ubuntu.com>>
>
>              Modify settings or unsubscribe at:
>         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>>
>
>
>