Fwd: Screen Blanking Power Management Requirements

[Robert Carr]

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@**canonical.com<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<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>
>> >
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20130625/ff498eb6/attachment-0001.html>