Develop Bugs

[Q] is it possible to increase LCD brightness on Froyo ?

hello,
since the leaked Froyo Updates the screen is a little bit darker then before. Is it possbile to increase the screen brightness on froyo roms ?
Maybe this seems to be the reason Froyo saves more power then Eclair.
any ideas ?
thanks

Just go to settings/display/uncheck auto brightness and move the slider to your liking.

i have already moved the slider to maximum brightesns - but it not as bright as before with Eclair.

yeah. i have noticed this one too. have compared several times the brightness of the eclair to froyo and there is a great difference comparing the 100% brightness

Hmm, strange. I know by default the Froyo version has night mode on by default. I wonder if that has anything to do with it?

Try to use this app;ledefy

Is there someone who has already found a real solution? The thing with the brightness is very, very bad.
The screen goes dark after the vibration on boot progress. The kernel is load before, isn't it? Then normally this should be no problem to increase the screen brightness for the devs?
In hope, greetz from Germany!

echo 1 > /sys/class/leds/lcd-backlight/als
Click to expand...
Click to collapse
or use ledefy

slph said:
echo 1 > /sys/class/leds/lcd-backlight/als
Click to expand...
Click to collapse
How you can set this value after boot? Is there any init folder from where you could run a script?

download terminal emulator and run this command, this should fix the brightness (it did it for me) providing that your phone is rooted!

zakoo2 said:
download terminal emulator and run this command, this should fix the brightness (it did it for me) providing that your phone is rooted!
Click to expand...
Click to collapse
Right, but I won't do that each time after I rebooted my phone.

Great! Works fine....there's a way to auto execute this command on startup?

I don't know how to execute this command on startup but i'm using the ledefy app (ledefy.com). There you can set the increase brigthness fix and autostart on startup.
Furthermore it will give you a nice battery icon in the status bar with 1% steps and various other fixes...

ledefy does not work on CM7
becaus every time i switch of my screen, the brightness will be decreased to the CM7 default brightness. If i switch on my screen i can increas brightness again with ledefy.

What exactly does this line?
"echo 1 > /sys/class/leds/lcd-backlight/als"
Is it setting backlight fix to a MAX or is it increasing the range of control?
If it is increasing the range - is it works for automatic or manuel or both?
What is the default value to go back?

Tweaking the screen refresh

In /sys/class/graphics/fb0/, there are some interesting options :
epd_percent (default: 85) "EPD Flushing Update percentage for AUTO Mode" is the percentage of the screen that has to change to trigger a full refresh of the screen
epd_delay (default 100) "EPD Flush elimination window (ms) for AUTO Mode" is the time before a full refresh apply.
pgflip_refresh (default 0) If you set it to 1, it disables the full refresh when reading a book (with the stock app)
There are other options in this directory but I don't know what they do.
Disclaimer : I'm not responsible if anything happen when editing these files. (It is possible that some values are dangerous for your nook, I don't know)
Increasing the value of epd_percent can be useful to have less flashes or to increase the speed of page scrolling in the web browser. (but you may have more ghosting)
Decreasing the value of epd_delay allow faster full refresh (but if you decrease it too much when you scroll a page, you will have several full refresh instead of only one)
epd_percent and epd_delay have no effect in the stock reading app
How to modify these options ?
Method 1: with adb
Example :
Code:
adb shell
# cd /sys/class/graphics/fb0/
# echo -n 90 > epd_percent
# echo -n 60 > epd_delay
(With this method, these values will be reset at each boot)
Method 2: adding the previous commands at the end of /system/bin/clrbootcount.sh (this file is executed when the boot is completed)
Code:
adb pull /system/bin/clrbootcount.sh
//Now you can edit this file and add at the end a command (like echo -n 95 > /sys/class/graphics/fb0/epd_percent for instance)
//Then
adb shell mount -o remount,rw /dev/block/mmcblk0p5 /system
adb push clrbootcount.sh /system/bin/clrbootcount.sh
adb shell chmod 755 /system/bin/clrbootcount.sh
Method 3
Modifying the init.rc in the uRamdisk (untested)
Code:
# Set EPD Flushing Update percentage for AUTO Mode.
write /sys/class/graphics/fb0/epd_percent 85
# Set EPD Flush elimination window (ms) for AUTO Mode.
write /sys/class/graphics/fb0/epd_delay 100
- More information here

Are your sample values the ones you recommend?
What are some "limits" you've found (upper/lower; at XX value, you get multiple refreshes...,etc)

Sorry for the late answer.
I have not found any limit (I even tried 0 in epd_delay and it works).
My sample values are values that I found rather good but it really depends on your preferences and on how you use your device.
So I would advise to test some values with adb before.
I noticed that I had a double refresh in some app when epd_delay < 80.
And with the 1.1 update, I find it less useful to modify them as the screen refresh is rather good with the stock values..

I never saw this post before and didn't know about these settings. They're pretty good.
I decided to just set epd_percent to 0, which I think may turn off the percent-based screen refresh (seems basically the same as setting it to 100). I do get a little artifacting in some apps, but usually not. It really makes using things like ES File Explorer a lot smoother.
pgflip_refresh is the really interesting setting, though. OP's description is not complete. While setting pgflip_refresh to 1 does disable full screen refreshes in the default epub reader, its more interesting effect is that the screen updates more often (or allows small partial updates maybe?). This is in all apps. It's especially nice in something like a text editor or terminal. With pgflip_refresh set to 0 (default) deleting with backspace or moving the cursor doesn't update on screen until you let off the key, so you have to try to guess how far you've gone. With pgflip_refresh 1, it updates just like on a non-eink screen, though with considerable blurring. I'd consider it a whole separate screen mode, similar to NoRefresh, but with the full greyscale graphics. In fact, if you use an app that's already 1-bit color, like e-Paper, pgflip mode and NoRefresh look identical.
Anyway, I advise playing with these settings if you've never done it before, you can make some more subtle changes compared to NoRefresh and FastMode. Note that when pgflip_refresh is on (set to 1), NoRefresh and FastMode will not work, so it has to be disabled first if you want to use them.

SweaterFish said:
I decided to just set epd_percent to 0, which I think may turn off the percent-based screen refresh (seems basically the same as setting it to 100). I do get a little artifacting in some apps, but usually not. It really makes using things like ES File Explorer a lot smoother.
pgflip_refresh is the really interesting setting, though. OP's description is not complete. While setting pgflip_refresh to 1 does disable full screen refreshes in the default epub reader, its more interesting effect is that the screen updates more often (or allows small partial updates maybe?).
Click to expand...
Click to collapse
Interesting. Setting epd_percent to 0 gives a flicker-free scroll, after a fashion, but it's really just a smear of lines going by without a flicker. Certainly in that respect, NoRefresh is a better deal.
I can sort of see what you mean about things like ES File Explorer although I confess I must have just gotten used to the typical screen behavior over the years so it doesn't seem like that big a deal to me. Using the text editor in ESFE I never see any flickering or other annoyances, so there's no gain there for me. There seems to be a visual improvement in simple navigation among folders with maybe less flashing, but that's at the expense of the scrolling behavior already described.
pgflip_refresh also seemed to make subtle changes. Page changes in the Kindle app (sloppy at best) were much improved with this change and the change in epd_percent. But, using NoRefresh (which is what I generally do with the Kindle app) gives a better result, IMO. Ditto with something like EBookDroid.
But the settings are interesting to look at and try out. Perhaps there's a "sweet spot" in there somewhere!
Edit: I should add that I tried these out using the text editor of ESFE and the changes appeared to be immediate. That means that a special combination would be easy to invoke/revoke by a simple Tasker app if it proved really useful. It would revert upon boot, of course, but even that could be addressed with the hypothetical app.

I see now that the behavior varies in different kernels. For kernels with FastMode support, setting epd_percent to 0 has less of an effect than in standard kernels. It's very subtle, but just fewer screen refreshes overall. With non-FastMode kernels, setting epd_percent to 0 and setting pgflip_refresh to 1 appear to do more or less the same thing, except that refreshes in the stock reader are also disabled, like OP said.
Another one to try is setting the permissions of epd_disable to 444 (read-only). This seems to disable refreshes when changing activities. Or maybe the refresh still happens, but since epd doesn't get disabled for the usual 100-300ms, you don't notice it. The screen just sort of dissolves between the two activities. I rather like it.
For me, these changes aren't so much about improving scrolling (I guess I don't do much on my Nook that involves scrolling), but just less flashing, which I really appreciate.

SweaterFish said:
Another one to try is setting the permissions of epd_disable to 444 (read-only). This seems to disable refreshes when changing activities. Or maybe the refresh still happens, but since epd doesn't get disabled for the usual 100-300ms, you don't notice it. The screen just sort of dissolves between the two activities. I rather like it.
Click to expand...
Click to collapse
This seems to have little general effect on a non-FastMode kernel. There is improvement in the page turns for the Kindle app, but otherwise transitions are pretty much what I am used to. NoRefresh is compatible with this change.

Screen brigthness, negative value?

This is a two part question. What screen brightness do you usually leave your phone at? I leave mine on what seems to be 0 (see next paragraph for explanation) and my screen still always uses around 60-70% of my battery. I don't understand how it can use that much without the backlight on.
Next question - When adjusting the screen brightness and the slider is all the way to the left is that 0? I'm asking because every widget out there when set to 0 is a a few times brighter than when I manually move the slider all the way to the left. Also, after using a widget to toggle to 0 and I check in the display settings, the slider isn't all the way to the left.
So I'm wondering what is true 0? What the widgets set it to or with the slider all the way to the left? Could the slider being all the way to the left actually be hurting my battery life?

No zero on the slider is technically not zero. You can confirm this checking your brightness sysfs file. You have to decompile framework and adjust some numbers. We can take it down to true zero or slightly above which would be much dimmer.
I did this for the atrix. Im surprised it hasnt been done yet for the nexus.

I know it is not actually 0 because if it was I wouldn't be able to see anything on the screen.
Is there anyone that has insight on my questions though?

I dont understand your question. Zero is not true zero unless we mod the framework. So your backlight is not "off". I dont know why youre getting so much drain.
But we should mod this anyway. Use root explorer and go to sys/devices/omapdss/display0/a6e8aa0 and open the brightnesd file. Note that value with your slider at zero and you will see a reading of 30 (0-255). So we can lower that down to maybe 5-10 and zero on the slider will be much dimmer = battery saving.

I have a similar problem. The max brightness is piercing and the min brightness is just a tiny bit too dim.
I have tried used root explorer to change the maximum brightness from 255 to 100 hoping that the slider may be more granular after. For some reason however I cannot update the max brightness file. I have ensured that it is r/w mounted and tried changing the permissions too. It says that the changes have been made and the original backed up. When I reopen the file it hasn't changed.
BTW, my 'brightness' file is at 10 when placed at the minimum brightness.

Try the newest AOKP.
Brightness controls.
I actually have NEVER used auto brightness...even back in my OG days.
And my X days.
Even when custom auto-brightness options were around I ignored them.
I'd simply keep it at around %20 of the default lowest value.
BUT...this is slightly annoying when you step into the sun and can't see anything.
With the newest AOKP you can even set the amount of brightness changes.
I set up four values.
I've mine set up for a pitch black room to lowest.
Average room to my previous 20%ish.
Bright (sunny) to 100/255
SUPER sunny to 240/255.
I didn't notice any added drain today.
But this was my first test.
I think this feature was actually kanged from CM9, but I'm not certain.

So far I have resisted the temptation to get flash happy and I am on stock 4.0.2 but rooted. Do I have any options without changing ROM?

aidanbree said:
I have a similar problem. The max brightness is piercing and the min brightness is just a tiny bit too dim.
I have tried used root explorer to change the maximum brightness from 255 to 100 hoping that the slider may be more granular after. For some reason however I cannot update the max brightness file. I have ensured that it is r/w mounted and tried changing the permissions too. It says that the changes have been made and the original backed up. When I reopen the file it hasn't changed.
BTW, my 'brightness' file is at 10 when placed at the minimum brightness.
Click to expand...
Click to collapse
We cant change that brightness file with root explorer, even mounted, unless we mod the driver first. It will likely just revert right back to its previous value.
However it is possible i bet to edit the driver. Would be a cool project. You could also try to echo your desired value in terminal. ie echo 255 > brightness. But you prob will get the same result as using root explorer.
Maybe ill look at the driver with my limited skills heh. Or the alternative is to mod the framework which is def possible to fix this, and easier. We did exactly this on the atrix. And the sgs2 had it done too.
Edit: i think i found the code for your granular request. Check lines 30 or so.
https://github.com/ogdobber/android...0/include/linux/platform_data/panel-s6e8aa0.h
Still would be easier to do in framework instead.

Density Change - Root/build.prop method

Gents,
I wasn't impressed with the display density on my G4. Appears to have been developed for the legally blind. So I attempted the ADB method and realized (like everyone else) there were a lot of glitches. Snapchat/WhatsApp picture cropping was massively zoomed etc.
So I rooted my device. All went well, everything else root works perfect. However attempting to use Texroider results in the Density being changed (according to the app) but nothing happening after a reboot. It looks identical.
So i attempted to edit the build.prop manually. Again editing the ro.sf.lcd_density and saving, after a reboot it still reflects the value I set (540/560) yet their is no visual change.
For some odd reason my device isn't reflecting the changes. Using the ADB method the device was showing the changes, albeit with the graphical/app glitches.
Anyone have ideas I'm stumped.
Cheers

open adb and type this in to it.
adb shell wm size reset
adb reboot
Then you can change dpi in build.prop file.

You need to the command mentioned here to reset the adb dpi changes you made as you set it to default instead of turning it off.
THOUGH afterwards I'd just stick with textdroider rather than modding your build.prop when finished.
TIP: Use App Settings with Xposed to set your Camera app to stock 640, as it removes the option to save internally or to SD and picks what it wants. Also there's some graphical glitches with some stock apps at lower DPI that you can fix on a per-app basis.
Also... For some reason Google Maps really hates when I change DPI on it and gives me blue rendering artifacts everywhere so I had to change it to stock.

Appreciate the help, unfortunately it had no effect. Obviously it is doing something as Swiftkey goes into massive zoom mode, but my launcher (ADW) and everything else remains the same size.

Yea, I would have thought resetting DPI with ADB, then using Textdroid would work. Could it be something in the cache needing cleared?
Maybe you might need to backup everything up, then reflash a kdz file then use Textdroid.

How To Guide Screen refresh rate twinkering

Screen refresh rate is controlled by several variables, 3 which I found are:
Code:
# getprop ro.surface_flinger.use_content_detection_for_refresh_rate
This instructs the screen compositor (surface flinger) to look at screen content to control screen refresh rate. 'true' by default; you will need root and Magisk's resetprop to override it, e.g.
Code:
# resetprop ro.surface_flinger.use_content_detection_for_refresh_rate false
But note that that does not stick after reboot, you will need a magisk module to force that upon boot. Add the property to system.prop file in the magisk module top directory.
Then:
Code:
# settings get system min_refresh_rate
0 by default; you can set e.g. to '60'
Code:
# settings put system min_refresh_rate 60
And the peak refresh:
Code:
# settings get system peak_refresh_rate
60 or 120 depending on toggle 'Smooth display' in Settings.
When you use 'Force peak refresh rate' in developer options then:
Code:
# settings list system | grep refresh
min_refresh_rate=120.00001
Weird number by the way. Anyway that forces the driver into 120Hz continuously.
I have personally set min=60, peak=120 and the surface flinger content detection to 'false' ... just to see how this goes for a couple of days.
And finally some other properties related to surface_flinger:
Code:
# indicates whether SurfaceFlinger should use refresh rate switching on the device, e.g. between 60 and 120 Hz (default: true)
ro.surface_flinger.refresh_rate_switching
# value used by the Scheduler to trigger display power inactivity callbacks (default: 1000)
ro.surface_flinger.set_display_power_timer_ms
# used by the Scheduler to trigger touch inactivity callbacks that will switch display to a lower refresh rate (default: 200)
ro.surface_flinger.set_touch_timer_ms

Interesting ...

It's possible to set minimum to 10Hz?

foobar66 said:
I have personally set min=60, peak=120 and the surface flinger content detection to 'false' ... just to see how this goes for a couple of days.
Click to expand...
Click to collapse
How did it go?

PuffDaddy_d said:
How did it go?
Click to expand...
Click to collapse
So far no issues ... all working fine. I have now set the minimum as well to 120 Hz ... just to see how that might affect things ...

foobar66 said:
So far no issues ... all working fine. I have now set the minimum as well to 120 Hz ... just to see how that might affect things ...
Click to expand...
Click to collapse
LOL ... as expected ... significantly more battery drain keeping the screen to 120 Hz all the time.
But scrolling ... oh so smooth ...
Looking for a middle with increased ground with ro.surface_flinger.set_touch_timer_ms to avoid switching too soon to lower rate (and ro.surface_flinger.use_content_detection_for_refresh_rate=false to avoid switching to lower rate based on content).

foobar66 said:
LOL ... as expected ... significantly more battery drain keeping the screen to 120 Hz all the time.
But scrolling ... oh so smooth ...
Looking for a middle with increased ground with ro.surface_flinger.set_touch_timer_ms to avoid switching too soon to lower rate (and ro.surface_flinger.use_content_detection_for_refresh_rate=false to avoid switching to lower rate based on content).
Click to expand...
Click to collapse
Can min=90? Or will it only run between 60-120?

kevinireland11 said:
Can min=90? Or will it only run between 60-120?
Click to expand...
Click to collapse
Not sure ... I guess it can ... I have not yet found if there is a kernel flag which can be checked to obtain the current (actual) frequency of the display.

Actually, you can see the refresh rate of the screen.
Go to developer settings. There is a toggle there called 'Show refresh rate' ;-)
Tried setting min rate to 90 ... but does not work via this mechanism.
Code:
settings put system min_refresh_rate 90
It switches the minimum rate to 120.
So looks like only 60 and 120 are accepted.
If you set system peak_refresh_rate to 60, then the screen will always be in 60 Hz. That is very clearly visible when scrolling.
When you touch the screen, it seems to immediately switch into 120 HZ as there is of course a possibility that you will start scrolling ... so makes sense. As soon as you lift your finger and the screen content is not moving the frequency is lowered to 60.

foobar66 said:
Screen refresh rate is controlled by several variables, 3 which I found are:
Code:
# getprop ro.surface_flinger.use_content_detection_for_refresh_rate
This instructs the screen compositor (surface flinger) to look at screen content to control screen refresh rate. 'true' by default; you will need root and Magisk's resetprop to override it, e.g.
Code:
# resetprop ro.surface_flinger.use_content_detection_for_refresh_rate false
But note that that does not stick after reboot, you will need a magisk module to force that upon boot. Add the property to system.prop file in the magisk module top directory.
Then:
Code:
# settings get system min_refresh_rate
0 by default; you can set e.g. to '60'
Code:
# settings put system min_refresh_rate 60
And the peak refresh:
Code:
# settings get system peak_refresh_rate
60 or 120 depending on toggle 'Smooth display' in Settings.
When you use 'Force peak refresh rate' in developer options then:
Code:
# settings list system | grep refresh
min_refresh_rate=120.00001
Weird number by the way. Anyway that forces the driver into 120Hz continuously.
I have personally set min=60, peak=120 and the surface flinger content detection to 'false' ... just to see how this goes for a couple of days.
And finally some other properties related to surface_flinger:
Code:
# indicates whether SurfaceFlinger should use refresh rate switching on the device, e.g. between 60 and 120 Hz (default: true)
ro.surface_flinger.refresh_rate_switching
# value used by the Scheduler to trigger display power inactivity callbacks (default: 1000)
ro.surface_flinger.set_display_power_timer_ms
# used by the Scheduler to trigger touch inactivity callbacks that will switch display to a lower refresh rate (default: 200)
ro.surface_flinger.set_touch_timer_ms
Click to expand...
Click to collapse
Hi, what's your experience with these changings now?
Can you send the exact settings for a script please?

For Samsung devices with high refresh rate displays there is Galaxy Max Hz, that has an adaptive mode (Pixel default from what i understand in the few hours ive been back on Pixel (6 Pro)) and also a screen off low rate, and also per app granular control. So far havent seen an equivalent for Pixel, but hopefully a matter of time

How to get magisk resteprop? I can't find anything about it

_Vortex95 said:
How to get magisk resteprop? I can't find anything about it
Click to expand...
Click to collapse
Its an applet of magisk, its functions are outlined here:
Magisk/tools.md at master · topjohnwu/Magisk
The Magic Mask for Android. Contribute to topjohnwu/Magisk development by creating an account on GitHub.
github.com
short version, you could call it via script (post-fs-data.sh OR service.sh - depending on at which point of the boot process you wanted to use it)
boot stages of magisk explained here:
Magisk/details.md at master · topjohnwu/Magisk
The Magic Mask for Android. Contribute to topjohnwu/Magisk development by creating an account on GitHub.
github.com
service.sh is preferred (see here for why: https://topjohnwu.github.io/Magisk/guides.html#boot-scripts )
but
as mentioned it would be easier to add it to a system.prop file it the root folder of a magisk module and try that first
and if you were looking to create a magisk module and fiddle, this template by @Zackptg5 is what id recommend and i use:
GitHub - Zackptg5/MMT-Extended: Magisk Module Template Extended
Magisk Module Template Extended. Contribute to Zackptg5/MMT-Extended development by creating an account on GitHub.
github.com
and his excellent wiki:
Home
Magisk Module Template Extended. Contribute to Zackptg5/MMT-Extended development by creating an account on GitHub.
github.com
A module might be as simple as (i could do it in about 5 minutes, (and it shouldnt take you much more as a 1st timer, as this is a simple module), but people should learn this themselves):
1) Download the MMT- Extended template linked above buy going to the github link, then click (towards top) green Code button, then Download Zip or click here: https://github.com/Zackptg5/MMT-Extended/archive/refs/heads/master.zip
2) Extract the zip somewhere, giving you a folder "MMT-Extended-master"
3) Rename "MMT-Extended-master" to the name of the module youre creating
4) Descend into this folder, delete what you dont need - in this case:
system folder
zygisk folder
changelog.md (unless you plane to update and maintain a changelog)
update.json (unless you plan to submit to a repo)
5) Edit module.prop to set values for the module name etc (remove the update updateJson line if you removed the update.json file)
6) Add a system.prop file in the folder
7) Open with a good text editor (notepad++ is reocmmended) and add the necessary line:
Code:
ro.surface_flinger.use_content_detection_for_refresh_rate false
8) Save the file
9) Select all the contents of the folder, and compress (preferably with anything but WinRAR (as it can create wonlky zip files))
10) Transfer to device, flash via Magisk Manager (NOT TWRP) and test
Only if this way fails would i bother with trying to add the resetprop method buy adding the
Code:
resetprop ro.surface_flinger.use_content_detection_for_refresh_rate false
line in service.sh (created in the folder), usually people would try this way with a delay (sleep <seconds>) to try and change it much later than the resetprop stage in system.prop...timing can sometimes be everything
Magisk modules dont need to be hard and thats a VERY simple one

Came across this in my travels today(not tested by me), just linking for interested parties
GitHub - yc9559/dfps: Dynamic screen refresh rate controller for Android 10+
Dynamic screen refresh rate controller for Android 10+ - GitHub - yc9559/dfps: Dynamic screen refresh rate controller for Android 10+
github.com

I have a Pixel 6a, might it be possible to reduce the Refresh Rate to 30Hz with this method?
Btw: Thank you for sharing your knowledge/findings guys!

You don't want it forced high all of the time. It's supposed to get low when you're on for example, always on display. You don't need root to edit this, all you need is the settings database editor app, and granting it the write secure settings permission through adb. You'll see the areas for minimum refresh rate, maximum refresh rate and user set refresh rate. You can also use the LADB app and set up wireless debugging and type in CMD display, and from there you can change the display size, HDR formats and refresh rate