• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category LCD
  • Assigned To No-one
  • Operating System Sansa AMSv2
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.7.1
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by bertrik - 2010-11-28
Last edited by bertrik - 2012-04-14

FS#11778 - Backlight fading for Sansa Clips

Attached patch enables “backlight” fading for the Sansa Clip players, i.e. Sansa Clip v1, Clip v2 and Clip+.

These players don’t really have a backlight since they use OLEDs which produce light themselves, but it has an effect similar to fading the backlight of a back-lit LCD.
The LCD “contrast” option is now gone and has been replaced with a “brightness” option. The brightness can be set in 11 steps, according to a table that attempts to straighten the non-linear relation between the LCD brightness setting and actual brightness. The lowest level is already quite bright, this is a hardware limitation.

After applying the patch, you probably need to do a ‘make dep’ or a ‘make clean’ to prevent compilation errors, because some files have been moved/merged.

I have tested this myself on my Clip v1 and Clip+, it’s untested yet on the Clip v2. Please test if the fading works for you and if the button light still works as before.

Closed by  bertrik
2012-04-14 10:08
Reason for closing:  Out of Date

I tried this patch on a Sansa ClipV2, and it appears to work handsomely. However, as you mentioned, the fading effect is not very pronounced.

One word of warning for people trying out this patch: You should make sure that the files this patch wants to delete are actually deleted (manually or through “patch -E”). Otherwise, dependencies will be miscalculated and there will be warnings about some function prototypes not being found.

Updated to resolve merge conflicts.

I strongly suspect that this patch is triggering occasional crashes. I have been running my ClipV2 with this patch and backlight fading turned on and off for more than a week now, and I repeatedly have experienced crashes when it was enabled.

As the crashes typically occurred when I would have expected the backlight status to change while executing some other operation, there may be a race somewhere. Examples: backlight turning on shortly before track change (with Caption Backlight option); backlight turning off after USB connection has been established (I’m using Rockbox USB as per  FS#11664 )

Hm, you could be right. The “backlight brightness” is set by writing to the controller controller, while on other targets the backlight is often independent from the display controller. This could result in concurrent writes to the display controller, causing trouble.
Not completely sure yet how to fix this, perhaps use a mutex for all display operations.


Could you please elaborate a bit on the potential concurrency issue you see?

I’m asking because I suspect that this patch only exacerbates an issue that’s present even without it: After backing out this patch, I am still experiencing occasional hangs when I would have expected the backlight status to change – very seldom, much less often than with the patch enabled, but still sometimes.

sideral, the concurrency I was afraid of, is between the backlight thread updating the brightness and some other thread (I don’t know exactly which one) updating the lcd through lcd_update. Now I’m not so sure about that problem, because we don’t do pre-emptive multitasking and we don’t block in the lcd driver.

Although we do not have preemptive multithreading, we do have interrupts. Perhaps the brightness is also updated from interrupt handlers (to light the display up in response to a key press, for example?). If that’s true, we may have to protect display updates from being interrupted.

By the way: During my background-noise explorations (FS#11915) I made an observation related to the minimal brightness of the OLED display. I noticed that enabling current feedback mode in the DCDC15 register seems to allow scaling the brightness via modifying ISINK1, allowing a much darker display than possible with stock Rockbox or with your patch. I don’t know whether doing so has any detrimental effects OLED display affecting its long-term health, but I found it interesting nonetheless.


Available keyboard shortcuts


Task Details

Task Editing