Smart Backlight

[TheBashar]

I would love to see an option to keep the backlight off when pressing keys which have an immediate effect and do not require viewing the screen.  Keys like track forward / back, volume up / down.  This would save a lot of battery when listening to music and only need occasional volume adjustments or track skips.

It looks like there is already a patch to do this for the c200.  It would be nice to have this ported to the other supported players and included in the standard builds.

http://www.rockbox.org/tracker/task/8400#comment24304

[Zardoz]

I like this idea. Maybe configurable in terms of exactly what keys or combinations provoke the backlight?

[JdGordon]

its not going to happen...
technical reason:
the backlight is handled by the "firmware" level. as soon as a button is pressed the backlight is turned on.
"volume +/-, next/prev track" are handled by the "apps" level (one level above firmware). we have a fairly strict rule that code can only go apps->firmware (i.e firmware is not allowed to call any apps level code)

So, you have a problem where the backlight needs to know if the X button was pressed because we are in the wps and want to vol+, or if we are in a list and want to change selection.

possible solution:
move the backlight enabling code into apps/action.c. but 1) thats not very nice from a code POV, 2) it isnt a wanted feature anyway.

[Zardoz]

Fair enough. Thanks for the explanation. Z

[oayz]

Hmm, what about having diffrent timeout assign to keys?

[fml2]

its not going to happen...
technical reason:
the backlight is handled by the "firmware" level. as soon as a button is pressed the backlight is turned on.
"volume +/-, next/prev track" are handled by the "apps" level (one level above firmware). we have a fairly strict rule that code can only go apps->firmware (i.e firmware is not allowed to call any apps level code)

Couldn't the app layer register a 'filter' function which would tell to the backlight thread whether the backlight should be activated or not? The function itself would be at the app level and hence be aware of the current context. And whether the backlight should be turned on on a particular key press could even be specified in the key mappings thus allowing very fine grained tuning possibilities -- and in the right context.

[TheBashar]

Couldn't the app layer register a 'filter' function which would tell to the backlight thread whether the backlight should be activated or not? The function itself would be at the app level

I think that would violate the rule of not having firmware level code calling apps level code.  If the feature requested is to make the backlight have application context knowledge, the straight-forward fix is to move the backlight activation code up to the apps level.

[fml2]

I think that would violate the rule of not having firmware level code calling apps level code.  If the feature requested is to make the backlight have application context knowledge, the straight-forward fix is to move the backlight activation code up to the apps level.

I've created a patch, see FS#9305 I still think this does not violate the layering since the firmware code does not use app level API. And only that matters IMHO.

[oayz]

Couple of ideas:

- let f/w turn BL on but application can turn it immideatly off
-  make BL time-of-the-day dependent , e.g. no need for full BL beetween 7am-5pm

[delt]

- let f/w turn BL on but application can turn it immideatly off

Ideal solution imho.

-  make BL time-of-the-day dependent , e.g. no need for full BL beetween 7am-5pm

That would depend on the target player, for example my ipod nano's display is easily visible in the daylight with backlight off, but not the same for my sanyo. They probably use a different type of LCD, but i'm no expert on that.

[ryran]

Oh man. I so would be grateful to see a time-based auto-brightness setting.