Closed wavexx closed 6 years ago
Hi there, thanks for the report. I can reproduce it :)
In v3.2.0, I changed the intended behavior so that the brightness will not be restored if you've changed it since it was automatically lowered, under the assumption that this more recent value is a better reflection of what you actually want -- see #131. It seems that check is not working properly, and so the brightness is never restored.
I described it too in my recent comments elsewhere, as I found it quite annoying and frustrating expecially for the fact it doesn't even restore the very useful system settings of backlight-auto-adapt. You eventually find yourself in shining daylight, while your display becomes barely visible and obscure, since RM set system's backlight to minimum level with auto-adaptability switched off and didn't restore it to previous levels. Really problematic sometimes.
"RM doesn't correctly restore backlight settings which were previously selected on the system. I noticed this problem got worse after one release, don't remember which one. Now it only seldom restores them after it pauses (i.e. when morning hour comes and it auto-pauses). Of course, it never restores previous backlight levels and auto-compensate setting when it the system unloads it from memory. If it stored "user configured system backlight settings previous to filter enabling" somehow permanently for each session, could it then correctly remember them when it got restarted, even if it got unload from memory?"
Let me repeat once more that I love this app anyway and find it not only useful but really fundamental.
We do store the most recent backlight settings permanently. Currently this is only used to restore them across reboots, but it should be easy to modify that to restore if the filter is unloaded from memory, too.
@wavexx @barbaMimmo Since you both use this feature, would you be willing to chime in on #122?
Ha, I fixed this in 3f35d5f by accident.
On Thu, Sep 28 2017, smichel wrote:
@wavexx @barbaMimmo Since you both use this feature, would you be willing to chime in on #122?
I'm not sure all of this is needed. I agree that changing brightness should dim/[un]dim before changing the backlight when going under 0.
Ideally "dim" just doubles the dynamic range of the brightness, so that 0-50% is from maximum to zero dim (keeping backlight to 0), and 50-100% is zero backlight to 100% (keeping dim at 0).
If you could remap the system backlight control to this, then switching filters would be trivial (the current brightness is absolute). I have no experience with android development, so I cannot comment if that's actually doable.
However, when I switch off the filter, just restore whatever brightness was set before turning it on.
My specific use-case is super-simple: I just want darker, at night. I just use "dim", with the timer.
The red-shift is nice, but CyanogenMod includes a built-in feature for this (which I don't use). CyanogenMod also includes an adaptive brightness control, however the feedback is too slow and the resolution too low on the Moto G1 to be actually useful (it seems to be 3-4 steps at most).
I quite agree with @wavexx on the fact that a single slider could better control both patameters and will be glad to join the discussion on #122. My opinion is that as long as we are suited with the current way RM control backlight and dim, starting with it fully working is a very nice step. :-) So I'm looking forward to try the new release where you corrected the misbehaviour. Keep up the good work! Our eyes are so important!
I started to use RedMoon 3.0.0, which was working as expected on Android 5.1.1 (CyanogenMod 12.x). In all newer versions (currently 3.2 from F-Droid), the "Lower brightness" setting lowers the brightness, but never restores the original brightness when the filter is disabled.
I even cleared the settings (fearing some botched state), but to no avail. This used to work perfectly in 3.0.0, which unfortunately is no longer downloadable from f-droid.