This would hit only targets where the screen is readable without backlight. And if the user decided against backlight at all, it shouldn't be turned off, not even forced, I suppose. On the other targets (where you need backlight to read the screen), disabling backlight at all isn't a valuable option anyway (except for blind users maybe) and thus this wouldn't change anything.

IMO the whole point of the force functions is to override the current settings whatever they are. My view is confirmed by the fact that the lamp plugin does not work if the BL setting is set to OFF (try it on e.g. H120).

I like the idea of renaming it to ignore_backlight_timeout() - i.e. making a "timed out" backlight be in the on state, not the off state. If the user configures the backlight off always, or off on hold, then that is still respected.

Personally, on my H300, I configure backlight on a 20s timeout, plus off if HOLD is on. I'd want it to stay on during the plugin, but turn off when I enable the hold switch (and back on again when I disable it, of course).

buttonlight_force_on also does nothing when the buttonlight timeout is set to Off, causing the buttonlight functionality of the lamp plugin to fail. The same changes (if x != newvalue instead of if x > 0) could be applied to this function as well. I have the buttonlight switched off on my Sansa because I find it too bright - but when running lamp, bright lights are exactly what I want!

i think this change is reasonable.
* rename backlight_force_on to backlight_ignore_timeout to make the name suit what the function does.
* add function backlight_force_on that actually forces baclight to turn on and use this in lamp plugin.
in the other words, nothing is changed except lamp plugin always turn on the backlight.

i'd like to commit this in few days if no one object to.
if there are other plugins which make sense to force backlight on, then we can change them later.