Ask / Submit
20

Harbour API Request: Keep screen on/prevent screen blanking

Tracked by Jolla

asked 2015-05-19 03:45:45 +0200

MartinK gravatar image

As far as I can tell from the Harbour RPM validator source it is currently not possible to use the QML screen screen blanking control API in Harbour apps.

Minimal example of the API in question:

import Sailfish.Media 1.0

ScreenBlank {}

This effectively means that any apps that need to keep screen on for longer/indefinite periods, such as navigation systems, clocks, video players, speedometers, various status displays, etc. can't do that if they want to be accepted to Harbour. This reduces their usability quite a bit.

Example:

Using a navigation system on the Jolla while riding a bike - the user will have to manually turn on the display every 10 minutes (maximum keep-screen-on time in settings) as the navigation system can't prevent screen blanking.

On the other hand a package that is not Harbour compliant and uses the Sailfish.Media QML API can keep the screen on just fine.

tl;dr:

The Sailfish.Media import should be allowed for Harbour apps so that they can keep the screen on.

edit retag flag offensive close delete

Comments

you can use a dbus command to prevent sleepmode.

nightmare ( 2015-05-19 07:58:38 +0200 )edit

From QML? Any examples?

rgrnetalk ( 2015-05-20 01:52:09 +0200 )edit

3 Answers

Sort by » oldest newest most voted
7

answered 2015-05-19 11:30:01 +0200

thp gravatar image

There's the Nemo Mobile Keepalive project that provides a library and QML plugin to access this:

https://github.com/nemomobile/nemo-keepalive

We just need to stabilize, document and version it properly and then allow it in Harbour.

edit flag offensive delete publish link more

Comments

Yes, that would be ideal! Not only for Python & QML applications, but also just because the API is simple and easy to use #unlike mucking with DBUS from C++. Let me know if there is some way I can help with this. :)

MartinK ( 2015-05-19 15:53:59 +0200 )edit
3

answered 2015-05-19 09:28:21 +0200

While Media import is not allowed in Harbour you can use dbus which is allowed in Harbour. Example: https://github.com/skvark/SailKino/blob/master/src/kinoAPI.cpp#L283

edit flag offensive delete publish link more

Comments

Does the freedesktop dbus path don't work here?

Thaodan ( 2015-05-19 15:50:23 +0200 )edit

Any idea how that could be done from a QML & Python application ? IIRC the QML DBUS DBUS that could be used for this also is not Harbour ready.

MartinK ( 2015-05-19 15:51:29 +0200 )edit

Is dbus in python allowed? then pull mce in dbus too like skvark.

Thaodan ( 2015-05-19 15:56:02 +0200 )edit
3

answered 2017-01-11 19:07:16 +0200

velox gravatar image

updated 2017-01-12 16:55:41 +0200

Building on the dbus example given bei skvark, I've integrated an QML-only version into my sleep timer.

It didn't work well until I realized today that even the screen blank pause does time out after a while.

You should be fine* just copying this and using it as a Component: https://github.com/jgibbon/slumber/blob/master/qml/lib/ScreenBlank.qml

*) see comment below!

edit flag offensive delete publish link more

Comments

1

@velox Just fyi: There was a bug in mce (fixed in 1.1.9.x upgrade) that kind of allowed clients to skip the required timer based renews under some circumstances.

On a quick glance the qml code is still a bit incomplete logic wise (does not take lockscreen / display state into account), but probably works ok most of the time as long as users have not selected shorter than default dimming delay and display is not blanked (by the user) while the ScreenBlank component is left in enabled state.

spiiroin ( 2017-01-12 09:33:16 +0200 )edit

@spiiroin Thanks for your input! You're right, manual blanking is something I haven't thought about. Since I had some problems using the typedCall (If I understood correctly, that is required for querying stuff via dbus) I'll let it in that state, but I have updated my answer. In my quick tests, the mce query worked for longer than the set dimming delay (it was one minute with a set delay of 30 seconds, IIRC), so I guess it's more or less ok with the hardcoded timer duration.

velox ( 2017-01-12 17:02:43 +0200 )edit
1

@velox: The potential problem comes from: When display is off / lockscreen active, blanking pause sessions are terminated and further requests ignored -> if pause request is made just before display unblanks, there is now upto 30 sec window before the next request is made -> during that time normal blanking rules apply (and settings app allows using 15 second blank delay, manually even shorter period can be used).

Simply assuming that application is started / component initialized in display="on", tklock="unlocked" state & adding signal handlers to track changes to those states, it should be possible to stop/start timer based activity based on app wanting to prevent blanking and device being in a state where it is possible even without making explicit queries about initial tklock/display state.

  • signal void com.nokia.mce.signal.tklock_mode_ind(QString tklock_mode)
  • signal void com.nokia.mce.signal.display_status_ind(QString display_state)

Then again, even duplicating all of nemo-keepalive logic in custom qml would not future proof things (in case ipc semantics ever change or something). So it might be for the best to keep it simple as your current solution works ok except for some exotic corner cases.

spiiroin ( 2017-01-13 13:00:05 +0200 )edit

@spiiroin I agree wholeheartedly, thanks again for elaborating. Also, since I seemingly wasn't paying enough attention and didn't recheck, I somehow thought the minimum delay to set in gui was 30s. I've changed that in the qml file. After this, I also think the "should be fine" description for the technique is now valid. :)

velox ( 2017-01-13 16:02:25 +0200 )edit
Login/Signup to Answer

Question tools

Follow
5 followers

Stats

Asked: 2015-05-19 03:45:45 +0200

Seen: 902 times

Last updated: Jan 12