On Tuesday 16 June 2015 15:27:15 Richard Grooff wrote: > Apps can keep it from turning off: > "req_display_blanking_pause" and when app closes: > "req_display_cancel_blanking_pause".
Thanks Richard, but I don't want it to stop blanking, as the alarms can be up to 1 hour; I rather want it to unblank when the time has passed. Otherwise it would drain too much on the battery. > I use it in harboud-hud version openrepos. Do you have your code publicly available, so I could see an example on how to use it? > Regards, Richard /Thomas > 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 Tanghus
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org