Bugzilla – Bug 12889
Hook ambient light sensor to auto-brightness control
Last modified: 2009-10-05 14:31:18 UTC
Dunno if I'm missing this in the UI somewhere, but it appears that the brightness is not currently hooked up to the ambient light sensor. It should be :-)
Hi Raphael Do you think you'll find time to do something similar as you did for Fab4?
Raphael added a first version of that (r6968). Automatic mode can be enabled in the Brightness applet.
These are marked as CAT, yet that milestone is over now. Please re-target accordingly.
== Auto-comment from SVN commit #7165 to the jive repo by ccrome == == https://svn.slimdevices.com/jive?view=revision&revision=7165 == Bug #12889, Bug #12753. I implemented the lower brightness mode. This allows the baby display to go very dim. I had to change the applet code so that it uses the bl_power in the /sys interface to switch to dim mode. This required that each entry of the brightnessTable contains a pair of values, rather than a single value. I believe I got all the manual settings, but I think I broke the ambient light sensor code (which was kind of broken anyway). Raphael, would you mind taking a look at that, and see if you can see what I broke? The brightness is always an *index* into brightnessTable, rather than a value. This means that you don't want to be multiplying brightnesses, only adding and subtracting. Only setBrightness should dig into the brightnessTable values. -Caleb
Oops, this breaks PB1 units. (And maybe PB2 units). How do I check for board revision in lua?
*** Bug 12999 has been marked as a duplicate of this bug. ***
Manual brightness for PB1 and PB2 units fixed in r7189.
*** Bug 13555 has been marked as a duplicate of this bug. ***
*** Bug 13604 has been marked as a duplicate of this bug. ***
Comment 7 says 'fixed in pb1 and pb2' - is that so? Is this an issue for later versions? If OK in later versions, don't worry about pb1/2 units.
I thought when this bug was fixed we would have automatic brightness working based on the ambient light sensor. Comment 7 says that MANUAL brightness is fixed, but as far as I can tell, automatic brightness still doesn't work properly. When I set my PB1 for automatic brightness it just does an annoying strobe effect between two brightness levels whether the room is dark or bright. Is this something that can't or won't be fixed in PB1 units? Mine is on Firmware: 7.4.0-r7453. The lack of automatic brightness makes it difficult to test Baby in certain environments.
Is this really fixed? I'm not sure. Here's what I did with a PVT unit and firmware 7526: 1. I set Brightness->Brightness Control->Automatic Brightness. 2. I left in my kitchen overnight. Very dark. Plugged into wall with battery. 3. Before I left the kitchen for the night, I watched the brightness of the screen dim -- step by step, inc by inch. The screen was at a reasonable dim level before I left the room. 4. Next morning, the screen still looked dim. 5. I took it outside by disconnecting it from AC. It's an overcast day, and the screen was so dim I could barely read the screen. 6. Was somehow able to go back to Brightness->Brightness Control screen. The screen then got bright. I thought it might be OK without any adjusting, so I didn't make a change. 7. I put it down to start writing this bug, and the screen had automatically became super dim again. 8. I navigated back to Brightness Control screen and put it on Manual. I can now read the screen again.
Felix, could you see if Raphael has time to look at this over the next couple of days, or can you fix it?
This must be tested with a PVT or later unit. It can't be done on a PB1 or PB2 unit. -C
Caleb: How can a PVT unit be identified again? Is hardware version 3 good enough?
Right, HW rev 3, 4, or 5 would be fine
Mickey: Caleb fixed bug 14075 in r7594 which solves the issue where the display would stay dark even when the surrounding is bright again. I did some quick tests with r7594 and my Baby did behave as I would have expected it. I also talked to Raphael today and asked him to try to improve automatic brightness control while Baby is used. I.e. when the display is in active (not dimmed) state.
As discussed with Felix my changes to the brightness algorithm are as follows: - Automatic Brightness even if the Baby is in the ACTIVE state - Spikes in the returned lux values from the sensor are filtered out using average and standard deviation of the last 8 (MAX_SMOOTHING_VALUES) lux values. - Brightness Timer now runs ever 500ms How the new algorithm behaves can be controlled with the MAX_SMOOTHING_VALUES variable. The higher it is the bigger/more spikes are filtered out but has the side effect of delaying actual "big" changes to the brightness by 500ms * MAX_SMOOTHING_VALUES Please note I only tested on my R1 Hardware until my new one arrives.
== Auto-comment from SVN commit #7652 to the jive repo by felix == == https://svn.slimdevices.com/jive?view=revision&revision=7652 == Bug: 12889 Description: Checkin on behalf of Raphael.
== Auto-comment from SVN commit #7665 to the jive repo by felix == == https://svn.slimdevices.com/jive?view=revision&revision=7665 == Bug: 12889 Description: Changed some log levels to unclutter debug output.
Chris to review to see 1) what priority is 2) what correction should be made
== Auto-comment from SVN commit #7729 to the jive repo by felix == == https://svn.slimdevices.com/jive?view=revision&revision=7729 == Bug: 12889 Description: - Adjusted minimal brightness - Fix for spurious (wrong) values from ambient light sensor.
IMO, this is good enough to ship. If someone disagrees with me, the following changes should make it much better: Reported value Current brightness multiplier * 11 1 13 1 700 1 1286 1 1400 0.9 2053 1 2800 1 3800 1 7000 1.25 16500 1.25 65535 1 I will attach a more detailed report as a .pdf
Created attachment 5920 [details] Detailed test report
The auto-brightness is already pretty good. I just fixed a bug in the ambient light sensor code, so now it shouldn't have the spurious 65535 readings. The 65535 readings will still be the number of 'dark' but, it won't have spurious ones. That was fixed in Bug #14259, but only on trunk, not on 7.4.0. -Caleb
Hey, nice table Chris! Now I get your previous comment :-)
This bug as written has been fixed. See also bug 14341 and bug 14342 for continuing issues.
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server! * SqueezeCenter: 28672 * Squeezebox 2 and 3: 130 * Transporter: 80 * Receiver: 65 * Boom: 50 * Controller: 7790 * Radio: 7790 Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.