Fwd: Screen Blanking Power Management Requirements
Thomas Voß
thomas.voss at canonical.com
Wed Jun 26 05:14:34 UTC 2013
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
>
More information about the Mir-devel
mailing list