Warning: mysqli_real_connect(): Headers and client library minor version mismatch. Headers:50625 Library:50543 in /sites/rockbox.org/flyspray/adodb/drivers/adodb-mysqli.inc.php on line 108 FS#11778 : Backlight fading for Sansa Clips



FS#11778 - Backlight fading for Sansa Clips

Attached to Project: Rockbox
Opened by Bertrik Sikken (bertrik) - Sunday, 28 November 2010, 13:58 GMT
Last edited by Bertrik Sikken (bertrik) - Saturday, 14 April 2012, 10:08 GMT
Task Type Patches
Category LCD
Status Closed
Assigned To No-one
Operating System Sansa AMSv2
Severity Low
Priority Normal
Reported Version Release 3.7.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


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.
This task depends upon

Closed by  Bertrik Sikken (bertrik)
Saturday, 14 April 2012, 10:08 GMT
Reason for closing:  Out of Date
Comment by sideral (sideral) - Monday, 29 November 2010, 17:10 GMT
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.
Comment by Bertrik Sikken (bertrik) - Sunday, 05 December 2010, 22:00 GMT
Updated to resolve merge conflicts.
Comment by sideral (sideral) - Thursday, 09 December 2010, 14:02 GMT
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 )
Comment by Bertrik Sikken (bertrik) - Friday, 10 December 2010, 09:48 GMT
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.
Comment by sideral (sideral) - Tuesday, 08 March 2011, 13:07 GMT

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.
Comment by Bertrik Sikken (bertrik) - Tuesday, 08 March 2011, 16:58 GMT
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.
Comment by sideral (sideral) - Tuesday, 08 March 2011, 18:52 GMT
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.