Hi, after a minute or so doing nothing the screen dimms but is not restoring to the settings I had when I adjust the SCREEN BRIGHTNESS in SETTINGS. Is there a setting that is remembers the previous BRIGHTNESS SETTINGS?
2 Likes
try settings -> update
1 Like
That doesn’t solve it unfortunately
After the update, can you see that there are new “power options” in the “settings” ?
I see some the settings but don’t know if they’re new… which setting doesn’t have this?
If I look at the details of each setting it can not turned off…?
I have this problem too, it’s really annoying, if you let it idle it dims and never comes back.
Can you at least tell us how the dimming is done so we can fix it ourselves?
Update the launcher with “settings-> update” to v1.2 please.
Or if this file has been modified ?
Especially this line:
BackLight = “/proc/driver/backlight”
2 Likes
Nope I haven’t touched that, the only thing I’ve done is installed some retroarch dependencies to be able to compile directly.
If I let it idle for a few secs the screen dims, and then if I immediately press a button, it does go bright again.
But if you leave it for a while… say 3 minutes or so it never brightens up again until I go to the menu and do it myself.
Also it seems it never sleeps
Also since the update, I can’t seem to SSH in… I can still access via cifs but that sucks honestly… I hope I don’t have to open it up again to flash the sd card
NVM that fixed by itself…
Still the brightness issue persists
This will fix it: https://github.com/clockworkpi/launcher/pull/50
During the timeout check, it always resets the brightness. This means after double the dim wait time the screen would be dimmed again, updating the “last brightness setting” and blowing away the user brightness level.
no this will get buggy if user brightness is 1
gs wont never wake up from black screen
the old code is right , We just dont know how this bug happend
cause our gs are all working well
If the user’s brightness is 1 already this change will just not issue a redundant brightness set (as it always sets it to 1).
It has nothing to do with waking up the device as the sleep/poweroff state is described by the passout_time_stage variable.
If you’re correct, hit up dphys. The change was already merged in.
1 Like
Looking through the code history, I believe this may have been when this bug was introduced:
specifically the “if brt > 1:” change to “if brt > 0:”
your code wont change last_brt if user brightness setting was 1
so when screen closed
It can not restore brightness from last_brt
and code history is nothing to do with this issue
That history is because git rebase messed up the whole codes So I have to restore codes manually
gotcha, hit up dphys
the launcher itself is nothing but a git repo
I use git reset --hard #xxxxx <- short hash
to do the updating job
So May I suggest go to ssh and do a git clone from scratch
and see if this happend again
Because Now the GS here Is working well ,so we can not even repeat this issue here
I’ll re-clone the master repo (minus the latest merge, #50) and see if the issue is still present.
Ok, just ran the test against commit 3a93535eeb0d1373776de5c409a5649b093093b6.
The bug is present
Ran tests against commit 26ad1e57b42a3b75193c5479d332b88915fc31a7
The bug is gone
I ran tests in both Performance and Server power modes.
In Server mode, I waited until the screen blacked out and then verified that it would come back on in full brightness after the latest merge.
[edit]
Just ran a test in Power Saving mode and the screen blacked out and came back on when the countdown timer hit. I verified after resuming from that state the screen brightness was again set back to the user preference. I think we’re good here.
[last edit]
I did a final test with the device in Server mode and the display brightness at the lowest setting. You were right! This change does introduce a bug when those conditions are met!
I’ll have an additional pull request to fix this bug, thank you so much for your advice!
After a lot of testing I found out why you may not have been seeing the bug.
It is only present in Performance mode.
When the InspectionTeam is fired twice on passout_time_stage == 0, the “last_brt” is overwritten (which is why the screen stays on the dimness 1).
The early termination in RestoreLastBackLightBrightness (where the check for “last_brt == -1”) is what you were warning me about.
I was considering checking the main_screen._Closed status to fix this, but that is reset at the beginning of RestoreLastBackLightBrightness even if the method is terminated early by the last_brt == -1 check.
I’ll look more into this tomorrow, maybe you’ll have a better solution than what I’m proposing
ok
I’ll fix it right way
thanks man
1 Like