Fwd: Screen Blanking Power Management Requirements

[Thomas Voß]

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 <robert.carr at canonical.com> 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> 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>>
>>>
>>> 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>
>>>
>>>     Modify settings or unsubscribe at:
>>>     https://lists.ubuntu.com/__mailman/listinfo/mir-devel
>>>     <https://lists.ubuntu.com/mailman/listinfo/mir-devel>
>>>
>>>
>
>
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>