All backlight (and buttonlight) operation is done in the backlight thread apart from the rest of the code. The backlight thread accesses (initiates fading in and off) backlight fading by calling when the backlight times out:

There is no replacement for the target specific

These want to be called no matter of the fading. This is not also true for PWM fading. fading, although the the target specific functions have different names for historical reasons (could be fixed).

After fading is done, the backlight thread initiates putting the LCD to sleep, and wakes it up before fading respectively:

void backlight_lcd_sleep_countdown(bool start)

I, Backlight myself, can't tell very much about PWM fading (aka FIXME). functions in that way:

Changing brightness via PWM involves

• a) Setting up the ISR for the user timer hardware.
• b) Changing the PWM in that ISR in a fast fashion (several times per tick)

• a) setting up support for the timer interrupt
• b) accessing the backlight critical variables in an interrupt handler
• c) very low hardware latency in changing brightness (less than a tick)
• d) enough timer hardware to have a timer dedicated to PWM fading (it needs a timer interrupt driven implementation as of now). [Is this true?]

It delivers very smooth fading with virtually unlimited brightness levels.

For Therefore, it requires a hardware-side mechanism which is able to change the PWM (interrupt) backlight fading, there's currently one define: very quickly. Currently, it's implemented for a few iPods, the h100 series and the M:Robe 100.

For PWM (interrupt driven) backlight fading, there's currently one define:

The avaliable options are several overall times the backlight fading takes to toggle backlight completely.

Software brightness has two advantages: Backlight fading functions in that way:

• a) it doesn't need a dedicated timer interrupt Changing the brightness upon enabling and disabling the backlight through the available (limited) brightness levels
• b) it works even with sort of slower De/Incrementing the brightness level in a given interval fixed for a device in the backlight hardware thread
• c) easy to implement

With It's completely software driven. It's limited in terms of smoothness (although the disadvantage of: interval is optimized to be smooth) and configurability. It's relatively easy to adapt and doesn't require special hardware features. Additionally, it's dependent on the current backlight brightness value.

• being dependant on the currently selected brightness settings (lowest backlight setting means no fading).
• It linearly traverses through the available brightness levels, although the resulting brightness may not be linear.

There's 2 subimplementations, which are mainly caused by the subtle difference in hardware handling in brightness levels. There's a kind of controllers, that set the brightness to the lowest possible level upon backlight_off, while the other kind sets the backlight to off by setting the backlight brightness level to zero.

There's 2 subimplementations, which are mainly caused by the subtle difference in hardware handling in brightness levels. There's a kind of controllers, that set the brightness to the lowest possible level upon backlight_off, while the other kind sets the backlight to off by setting the backlight brightness level to zero.

This type is currently used by most Sansas, the h300 series, M:Robe 500, Cowon D2, Philips players and the Ondas.

There Backlight is a third way of implementing: Handling the fading functions in that way: only in hardware.

This means that all fading is handled in the very target specific "_backlight_on/_off(void)" function. Fading must be finished until _backlight_off/_on() returns to prevent confusion of the backlight thread (it will treat this backlight fading type the same way as no fading). No software controlled or interrupt driven backlight brightness changing is involved.

• a) Enable whatever bits the hardware needs to handle fading itself.
• b) Rockbox mostly completely ignores it, as it can't really control it. It offers settings though, as far as possible.

The configurability depends on the target, but It's completely hardware driven. Rockbox has no influence (at least currently only ON and OFF are used. for the targets that use it), other than toggeling it on or off.

All fading is handled in the target specific _backlight_on()/_off() function. Fading must be finished until _backlight_off/_on() returns to prevent confusion of the backlight thread. The backlight thread handles this type as if there was no backlight fading

The configurability basically depends on the target, but currently only ON and OFF are used.

Currently, only the Gigabeat S and Gigabeat F implement it, although the latter doesn't #define BACKLIGHT_FADING_TARGET and thus doesn't feature configurability.

(It's not strictly needed, as Rockbox doesn't acknowledge it. It only serves for adding the setting).