Apps can keep it from turning off:
"req_display_blanking_pause" and when app closes:
"req_display_cancel_blanking_pause".
I use it in harboud-hud version openrepos.
Regards, Richard
On Tue Jun 16 17:01:13 2015 GMT+0200, Thomas Tanghus wrote:
> On Tuesday 16 June 2015 10:51:29 Simo Piiroinen wrote:
> > On Tuesday, June 16, 2015 12:25:09 AM Thomas Tanghus wrote:
> > > On Friday 12 June 2015 12:47:42 coderusin...@gmail.com wrote:
> > > > check mce dbus. There is should be a method bot unblanking screen.
> > >
> > > Been away since Friday, but "req_display_state_on" looks like the one.
> >
> > Hi,
> >
> > the rule of thumb is:
> > "User turns display on, apps can keep it from turning off."
> >
> > Now, if you still absolutely need to turn display on, then note that:
>
> Thanks a lot for preventing me from pursuing the wrong path, Simo.
>
> When I get the time to work on it again, I guess it will be 2) in lieu of 4)
> -
> but first I have to make a successful dbus call :D
>
> > * Explicit display state requests like req_display_state_on, should be
> > avoided - they can cause subtle problems and/or easily end up ignored
> > altogether
> >
> > * Getting display to turn on does not mean the ui can be shown if the
> > display/device is locked
> >
> > Least problematic way depends on what the app is/does - terms of
> > similarity to sw existing on the device:
> >
> > 1) "Just show something on screen if applicable, no user interaction"
> > i.e. notification banners and such
> >
> > Start notification type blanking policy exception for relatively short
> > period that is not extended due to touch interaction - display comes
> > up during that period when/if sensor states etc allows it
> >
> > com.nokia.mce.request.notification_begin_req("context", 2500, 0)
> >
> > The "context" needs to be a string that is unique enough within the
> > process that is using it.
> >
> > If process exits, the exception state is automatically canceled, so
> > these can't really be tested with dbus-send & like. The mcetool
> > utility can be instructed not to exit when done, so something like
> > "mcetool --begin-notification=foo,5000,1000 --block" works.
> >
> > Note that the app should do this even if the display happens to
> > be on to make overlapping notifications work as expected (mce
> > blanks display only if it was off at start of the 1st notification).
> >
> > 2) "Prompt something simple from user" i.e. likes of usb mode
> > selection, headset volume warning, etc
> >
> > Start notification exception with long enough time for user to
> > understand what is happening, optionally extend the duration on touch
> > interaction (if user needs to type lock code or something)
> >
> > com.nokia.mce.request.notification_begin_req("context", 15000, 2500)
> >
> > When done, terminate exception but (optionally) keep the display on
> > for a while longer to give user a chance to continue with something
> > else without display blanking in between
> >
> > com.nokia.mce.request.notification_end_req("context", 2500)
> >
> > 3) "Novel call like ui"
> >
> > incoming call:
> >
> > com.nokia.mce.request.req_call_state_change("ringing","normal")
> >
> > answered/outgoing call:
> >
> > com.nokia.mce.request.req_call_state_change("active","normal")
> >
> > call ended:
> >
> > com.nokia.mce.request.req_call_state_change("none","normal")
> >
> > The display should turn on/off just like with normal calls.
> >
> > The call state tracking uses sender identification too, so several
> > processes can at least in theory do this without interfering with
> > each other. And state gets canceled automatically when process
> > drops from system bus, so dbus-send & co will not work.
> >
> > 4) "Novel alarm like ui"
> >
> > I guess to get this working properly it would need some new logic in
> > timed and/or mce. But the notifiction methods should work to some
> > extent.
> >
> > Hope this helps.
> >
> > simo
>
> --
> Med venlig hilsen / Best regards
>
> Thomas Tanghu
--
Sent from my Jolla
_______________________________________________
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
