Rockbox

definitely this is exactly what i waited for :-) hope this compiles well for all targets.
can it be turned on and off in the menu?

yes, General Settings/Display/LCD Settings/Which buttons turn backlight on.

With build r16061M for the ipod video target, the code patches without error but when compiling I receive a error

drivers/button.c:493:2: error: #error Can't guess BACKLIGHT_BTN_POWER for this targer
drivers/button.c: In function 'set_backlight_filter_buttons':
drivers/button.c:503: error: 'BACKLIGHT_BTN_POWER' undeclared (first use in this function)
drivers/button.c:503: error: (Each undeclared identifier is reported only once
drivers/button.c:503: error: for each function it appears in.)
make[1]: *** [/home/Jonathan/rockbox/build/firmware/drivers/button.o] Error 1
make: *** [build] Error 2

Thanks for this patch, I was looking for something like this for a while.

Yeah, seems like there's no POWER on iPod Video...
Ok, I thought a bit and here's version 2. Apply _instead_ of the first one.
Should work for iPod, please check it now.

I also like the idea. But while you're at it, why not make this setting an int with potentially many 'filters'? Now you have two but there could be more.

I just tested the new patch, it compiles successfully and the menu shows up in the compiled build on rockbox, but even when setting it up to deactivate the back light for volume and the left and right buttons, they still trigger the back light. I compiled with the latest build from svn.

Strange, current svn build works as expected on Sansa, and I can't figure out what may prevent it from working on iPod. Try changing BACKLIGHT_BUTTON in firmware/target/ipod/button-target.h, say leave only BUTTON_SELECT there. Also, check config file for "backlight on buttons" parameter -- is it there?

> why not make this setting an int with potentially many 'filters'?
> Now you have two but there could be more.
For the same reason keymaps are hardcoded in rockbox. No need to. You can always change it in button-target.h and recompile rockbox leaving no useless code in it. BTW, I removed second filter option in v2 patch

I edited the button-target.h (attached) to #define BACKLIGHT_BUTTON BUTTON_SELECT and checked to see if is in the config file and it is (attached) but it still triggers the back light with any action on the scroll wheel.

i made a build with only this patch, and it doesnt work for the wheel on the sansa.
the forward/back keys etc do not trigger the backlight, but the scrollwheel still does trigger it.
as the mein purpose of this patch is to disable backlight on volume+-, i consider this is a bug?
(current svn as of a few minutes ago)

Anyone tried this on an iRiver H300 yet? Been getting some requests to add this in, but I wanted to know if I just had to add the patch, or download the two attachments that Mr. Gorin has so kindly provided as well? I have no qualms with changing the source before any patches, just wanted to know how this one is supposed to be applied.

We should have a small plugin that comes with this that will allow you to choose what button to use. And also have a way to detect the play it's on? Maybe different versions for different targets?

This patch seems to work on some targeted builds but not others, it compiles successfully with rockbox-backlight-keys-v2.diff and the option is clearly visible from rockbox's menu, but the function does not seem to work for the ipod 5.5gen player. I would say try and apply the rockbox-backlight-keys-v2.diff only and see if it affect the iriver H300 and if not you will have to take a look at the source to see if you can catch the problem (due to inexperience with C I am unable to locate the exact problem.) Hope that helps.

did any1 get this patch working on sansa?

Josh Dionne: To build it, apply v2 (or v3 now) patch only, that should be enough.
You can select those buttons by changing
#define BACKLIGHT_BUTTON
in button-target.h for your specific device. Also, any feedback will be appreciated.

Regarding other targets — sorry, I'm totally puzzled, simulator seems to work well and still I have no real
devices to test it on. Here's v3, which won't break simulator builds like v2 did ;-), and a small
patch to make it warn you of what's going on. Try playing with them, maybe you'll get some ideas...

just one thing i noticed:
would it be possible to have an option to only disable backlight for volume changes?
(imho options could be: all, not for volume, not for volume+trackskip, selected only)
the config-flags could be named all,novolume,novolumenskip,selected

the problem with having only menu and select enable the backlight is that you can easily go to a menu or other things without you noticing it (because the backlight doesnt turn on, but all keypresses are accepted).

another option would be to turn on the backlight as soon as another screen than the wps is displayed :-)

Downloading fresh SVN and will try patching with the new v3.diff

Got SVN r16195. Patched this (backlight_keys_v3) as well as multifont (1/22/08), BMP Resize (12/05/07), and the Rec_button patch. Will not compile, image attached is the error(s), and I cannot figure out what it's talking about. Looking at the source file, it looks fine. I know this has multiple patches on it, but I tried to build with each patch, and each time it's done this.

Josh Dionne: strange, r16200 with backlight_keys_v3 and multifont patches had no problems compiling action.c for target 11 (H320/H340) with binutils-2.17 and gcc-4.0.3. Which version of compilter/binutils do you use?
Also, which FS# are two other patches?

me (disorganizer): well, there were two options in the first patch, but after using it a while I changed that. The idea was that BACKLIGHT_BUTTON should contain all buttons which open menu etc., so try tweaking it. Or perhaps take relevant portions from v1.

Turning BL on as screen changes sounds much more appealing to me though, I'll think of it.

after thinking, propably it even is more efficient than watching the keys.
so if the wps is left, the backlight turns on. but if it still there after the keypress, it will stay off.

i changed the keypresses for a test to not turn on the backlight for left/right/scrollup/scrolldown. this seems to be the best setting, as all other keys also open up a menu on the e200.
i also noticed that on left/right (aka track skipping) the caption backlight still works, which is nice :-)

but now the bad thing is:
this ONLY works in the simulator. when putting the patch on a real device it does not work (scrollwheel does turn on backlight).
the simulator showed no output with your debug commands, also the values for scrollwheel-actions match.

so i wonder:
why dont i get a debug output from your debug patch for the backlight on scrollwhell actions?
meaning: is there another place where the backlight is turned on when i use the scrollwheel?

btw:
the patch needs synching in the english.lang patch.

another idea: wouldnt it be better to modify your debug patch to capture the "backlight_on" function calls?
if the scrollwheel fires backlight_on but your original debug patch does not trigger, there must be some other function calling backlight_on when a scrollwheel action is detected, so your patch then needs to be expanded to also cover that function.

> but now the bad thing is: this ONLY works in the simulator.
Yeah, that's the main problem, as simulator is all I have.

> is there another place where the backlight is turned on when i use the scrollwheel?
there's buttonlight_* that can be triggered, and there's remote_backlight_* but e200 lacks
remote display, and seems like that's all.

> another idea: wouldnt it be better to modify your debug patch to capture the "backlight_on" function calls?
It's not that easy, but on simulator any call to backlight_on will result in subsequent call to sim_backlight, so effectively it's the same.
For the real device... here's a patch to make it more talkative, and second one to make logf() write on primary lcd. Perhaps it will give some clues.
Don't forget to enable logf support during build.
Also, feel free to add logf() to suspicious places, it should work almost anywhere.

i think i found something:
in file firmware\target\arm\sandisk\sansa-e200\button-e200.c there is a call to backlight_on() in line 197.
as far as i understand the code, this controlls the backlight behaviour for the scrollwheel.

i dont have my sansa handy right now so i cant compile and check, but i think this may be the cause for the "problem". could you check whether this could be the cause?
if not it will take some time until i find time and access to my e200 *g*

experimental patch to allow the e200 to not turn on the backlight on volume change or trackskip.
i commented the "backlight_on()" call in button-200.c to disable it.

i could not test it, but imho it should work (only for e200!).

at least it patches against 16213 without errors and compiles without errors :-)

if someone with an e200 is willing to test:
* try with "backlight on all keys" whether the scrollwheel still turns on the backlight. is there any difference when using the scrolllight?
* try with "backlight on selected" and check the scrollwheel now does not turn on the backlight.

Alright, got it to work wonderfully on H300. Using r16213, and I am pretty sure there was another patch, but not quite sure which one as of now. So much to do during the day, and not enough time, ya know?

i tested my patch above, and it works too good.
even in the menu the scrollwheel is not recognised as movement, resulting in the backlight going off even if you move the scrollwheel. *sigh*

hmm. so the next question is:
how can i let button-200.c know whether the active screen is the wps or not?
or said in another way:
as the scrollwheel turns on the backlight in button-200.c, how can i distinguish between "volume up/down"-moovements or "menu navigation" moovements of the scrollwheel?
or saind in yet another way:
if i disable the backlight_on() call as mentioned above, how can i ensure the backlight is turned on as soon as menu navigation is used instead of volume controll?

I think this is a general problem of how the backlight is turned on. It's done at the 'firmware' level, i.e. without knowing the app context (WPS/menu/...). To implement the feature right, one should IMHO maintain (in the app layer) a flag telling whether the backlight should be turned on if a key is pressed. And push the value of the flag (on every change) down to the button driver (or to the backlight thread). I don't know how easy or difficult it would be to implement such flag. It might be just a couple of places (e.g. menu function and WPS function) but it also could be all over Rockbox code. Someone with better code knowledge should tell. JdGordon?

during irc yesterday someone braught up the idea to have a variable in button?.c and a function to toggle this variable when the wps is displayed and toggle back when the wps is left into another screen via a function call (in button?.c).

this variable could then be use to toggle whether the backlight should be lit on every buttonpress and scrollwheel moovement or not.

as im no programmer im sadly not in the condition to implement this.

Resync

Resync

Resync

Disregard the above patch I made a mistake on it. Use this one.

Hello I love this patch, only have one problem with it: When changing volume, skipping tracks, etc the screen does not light up (this part works properly), but the button lights do light up. I would prefer the button lights to stay off when the screen stays off, and only be triggered by SELECT, MENU, or POWER, just as the screen light is.

Sorry for the double post, I forgot to mention I am using a Gigabeat F.

I too love this patch! However,as Michael Hahn has said menu navigation and volume control behaviors cannot be separated treated by this patch.

I have an alternative idea: The short REC button is rarely used except for the recording screen to start record (you can also press PLAY to achieve this action). So why don't we invest this REC button to be the backlight switch?