release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Wiki > Main > BacklightFading (compare)

Difference: BacklightFading (r6 vs. r5)

Backlight fading

Welcome to the Backlight fading API page. This page aims to describe numerous approaches to achieve backlight fading.

Work in progress

The backlight thread

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:

void backlight_setup_fade_up(void)

and

void backlight_setup_fade_up(void)

Both set the prerequisites for the fading process. The fading process depends on the actual implementation.

The settings can access the fading and change its behaviour by calling

void backlight_set_fade_out(void)

and

void backlight_set_fade_in(void)

There is no replacement for the target specific

void _backlight_on(void)

and

void _backlight_off(void)

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)

PWM backlight fading

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:

  • BACKLIGHT_FADING_PWM

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

Software driven backlight fading

Currently software driven backlight fading is solely implemented by changing the brightness in a given interval based on the total available brightness levels.

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.

Therefore there's two defines:

  • BACKLIGHT_FADING_SW_HW_REG and
  • BACKLIGHT_FADING_SW_SETTING

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.

The available options are limited to ON and OFF. Using timer options are generally possible, but are likely to be problematic with high latency backlight changing hardware and/or being choppy while fading due to a rather high timer.

Handling backlight fading target specific

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.

The corresponding define is

  • BACKLIGHT_FADING_TARGET

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

r7 - 06 Jul 2009 - 08:51:33 - MaurusCuelenaere

Revision r6 - 06 Jul 2009 - 00:34 - ThomasMartitz
Revision r5 - 03 May 2009 - 14:45 - MaurusCuelenaere
Copyright by the contributing authors.