This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#11778 - Backlight fading for Sansa Clips
Attached to Project:
Rockbox
Opened by Bertrik Sikken (bertrik) - Sunday, 28 November 2010, 14:58 GMT+2
Last edited by Bertrik Sikken (bertrik) - Saturday, 14 April 2012, 12:08 GMT+2
Opened by Bertrik Sikken (bertrik) - Sunday, 28 November 2010, 14:58 GMT+2
Last edited by Bertrik Sikken (bertrik) - Saturday, 14 April 2012, 12:08 GMT+2
|
DetailsAttached 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, 12:08 GMT+2
Reason for closing: Out of Date
Saturday, 14 April 2012, 12:08 GMT+2
Reason for closing: Out of Date
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.
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)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.
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.