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.
There seems to be very little actual documentation on the various eInk update modes.
Most of the information seems to have been extracted from working code.
Some of that code does not seem to be optimal in any case.
I'd like to start this thread on a discussion of the update modes.
You can look at all the code posted, but the bottom line is that eInk mode is configured by passing six discrete pieces of information to the EPD driver.
These six pieces may be wrapped up into a single static entity.
Name of entity requesting change (for logging purposes only)
Region, one of enumRegion[] (Region 4-7)
A rectangle, normally {0, 0, 600, 800}
Wave, one of enumWave[] (GC, GU, DU, A2, GL16, AUTO)
Mode, one of enumMode[] (INACTIVE, ACTIVE, ONESHOT, CLEAR, ACTIVE_ALL, ONESHOT_ALL, CLEAR_ALL)
Threshold, an int 1-15, only applies to A2 mode
A2 is the one bit, fast drawing method. It leaves ghosting behind.
In some applications, you would like to enable faster scrolling in A2 mode and then have it revert to "normal" upon completion.
I have an application with a full screen scroll.
After experimenting with the values, these two configs seem to do the job nicely.
Code:
configA2Enter = makeConfig(rpc, waveEnums[WAVE_A2], regionEnums[REGION_6], modeEnums[MODE_ACTIVE_ALL], THRESHOLD);
configA2Exit = makeConfig(rpc, waveEnums[WAVE_AUTO], regionEnums[REGION_6], modeEnums[MODE_ACTIVE_ALL], 0);
No user intervention is necessary, it scrolls quickly and redraws a clean image when done.
(A view.invalidate() is necessary after you invoke configA2Exit)
Does anybody have any further insight into these values or suggestions for improving them?
Some additional information on the A2 ("no refresh", 1 bit) mode.
Some of the other modes can be selectively applied to portions of the screen.
The A2 mode may only be applied to the entire screen.
The threshold value, which some may construe as "brightness" or "contrast"
is the cutoff threshold between black and white of the original image.
A value of 1 will only generate black in the darkest areas of the original image.
A value of 15 will only generate white in the whitest areas of the original image.
That is, 1 will give you a light image, 15 a dark image.
Renate NST said:
Some additional information on the A2 ("no refresh", 1 bit) mode.
Some of the other modes can be selectively applied to portions of the screen.
The A2 mode may only be applied to the entire screen.
The threshold value, which some may construe as "brightness" or "contrast"
is the cutoff threshold between black and white of the original image.
A value of 1 will only generate black in the darkest areas of the original image.
A value of 15 will only generate white in the whitest areas of the original image.
That is, 1 will give you a dark image, 15 a light image.
Click to expand...
Click to collapse
Nice find! I didn't know that was a B/W threshold. But I think you meant "1 gives a light image and 15 a dark image".
I've just tried using this in NoRefreshToggle, but the result was not as good as before. The image is much more just solid black and white because you can't see the dither patterns that represent grey (they appear only at very specific white levels, which would be nice to tweak too).
What I actually use for "contrast" adjustment in NoRefreshToggle is a different approach. Using a fixed threshold of 14 (dark image), I've managed to lower the black level (turning it more greyish) to achieve a smaller color range. This way, the dither patterns appear more often. However, my technique to achieve this effect is not so elegant: I overlay the entire screen with a semi-transparent white pane. This has the inconvenient of controlling the pane visibility: whenever A2 mode is turned off (by user or system), I need to hide the pane View.
If I could temporarily avoid the automatic changing of screen modes by the system, this would be much simpler. I've had no success at this issue so far.
marspeople said:
I think you meant "1 gives a light image and 15 a dark image".
Click to expand...
Click to collapse
Yup, good catch. The preceding two sentences were correct. I edited the third.
I have a demo panning grayscales. It's easy to see where the threshold is occurring. Shown below.
Oh! I did see something about the dither modes.
They would certainly be useful for video, less so for text.
I think a system-wide use of A2 would be a bit counterproductive.
The fonts look better with 16 shades.
The best use would be to have browsers and viewers use A2 for panning and zooming.
And another thing:
I don't know how you are getting the dither in there, but since you are doing an overlay anyway,
maybe you should try a halftone screen approach to see how it would work.
The simplest halftone screen would be a checkerboard with two different transparencies.
That wouldn't sacrifice too much resolution.
Renate NST said:
I think a system-wide use of A2 would be a bit counterproductive.
Click to expand...
Click to collapse
i seems to me that n-r mode would be much more usefull if would could regulate when its on a and when off. Its quite pain running the app again and again. it seems to me that quicker reaction is much better than nicer pictures in average use - pdf reading, browsing, video, managing system...
marspeople said:
I've just tried using this in NoRefreshToggle, but the result was not as good as before. The image is much more just solid black and white because you can't see the dither patterns that represent grey (they appear only at very specific white levels, which would be nice to tweak too)
Click to expand...
Click to collapse
I don't think the dithering can be 'tweaked' as such. It's caused by the reduction of 24-bit color images to the 16-bit colorspace of the OS. Dithering is performed by the graphics hardware to prevent obvious colour banding, and there's no OpenGL functions to control dithering parameters.
The A2 mode seems to choose a threshold value for black in the 16-bit colorspace. Values above this are white. In order to obtain black and white dithering we have to pick values in the 24-bit colorspace which all lie in the same 16-bit band.
The easiest way I've found is to keep the R and G values at 255 and vary the B value. I think the default threshold lies at 255,255,198. If you start at that and increase the B value you get 7 dithered grey shades before you reach white.
Guys, as far as i know, eink display is build of tiny capsules, much smaller that one pixel is, and a chip is joining them into pixels. So mayby there is a way to divide single pixel into 2 or even 4? It is much much work, but it would make us easier draw some tones of monochrome? Example: to get dark gray, instead of displaying one of five black pixels white, we can make one's "subpixels" 3/4 black, 1/4 white.
Does it make sense/do you get it?
Renate NST said:
I think a system-wide use of A2 would be a bit counterproductive.
The fonts look better with 16 shades.
The best use would be to have browsers and viewers use A2 for panning and zooming.
Click to expand...
Click to collapse
I agree with you. But having temporary exclusive control of A2 mode would make my application more efficient. I don't intend to use A2 system-wide.
Renate NST said:
And another thing:
I don't know how you are getting the dither in there, but since you are doing an overlay anyway,
maybe you should try a halftone screen approach to see how it would work.
The simplest halftone screen would be a checkerboard with two different transparencies.
That wouldn't sacrifice too much resolution.
Click to expand...
Click to collapse
I just tried this but I've got nothing more than a simply darker and checkered image. I don't understand how it would be better.
marspeople said:
I don't understand how it would be better.
Click to expand...
Click to collapse
Well, halftone screens have been around forever.
Think of it this way, it would give you two different thresholds.
With a bigger pattern you would get more thresholds but a coarser pattern.
That is always the way with dithering or halftone.
Probably a screen would not work well with an underlying dither.
A useful observation from http://forum.xda-developers.com/showthread.php?t=1502723&page=11 is that by listening to the screen you can hear screen activity.
After a quick test I suspect ONESHOT mode allows the screen to enter a power saving mode (in which the screen is completely silent) after a few hundred ms of inactivity, while ACTIVE prevents it. No idea whether there are other issues involved.
The native Reader.apk uses GU, ONESHOT_ALL when turning pages.
Every 6th page it uses GC, ONESHOT_ALL.
In an overnight test with the nook screensaver / lock screen mode inhibited by my application and no screen updates, I obtained power consumption of 0.75% / hour with ONESHOT mode. In a previous test with ACTIVE mode I got ~7% / hour with the same scenario(!)
With fast screen updates of ~ 1Hz ONESHOT does not appear to give any power saving benefit over ACTIVE mode, and a quiet hiss can be heard from the screen at all times in both modes at this refresh rate. I think this indicates the ONESHOT mode allows the screen to enter a power saving mode after a period of inactivity.
Neither of these were scientific tests but I strongly suggest trying ONESHOT mode in favour of ACTIVE whenever using A2 mode.
Well, there must be some benefit sometime to the ACTIVE mode or they wouldn't have it.
It's hard to differentiate the different modes, but it seem that ACTIVE responds quicker with less delay.
I switch to ACTIVE_ALL, A2 for panning and switch back to ONESHOT_ALL, AUTO afterwards.
(I don't use full-time A2).
See my demo of panning: http://forum.xda-developers.com/showthread.php?t=1563645
I'm running about 7%/hour drain. My Nook is not suspending when I do a simple power button click. I don't know why.
A few folks seem to be using EpdController in a useful manner.
Their use of Java reflection is clever, but it's not supposed to be that difficult.
I wrote a Java stub (basically declarations) for EpdController and wrapped it in a jar.
If you just put this jar in your compilation classpath with your normal android.jar
then you will be able to use the EpdController without all the fuss and muss.
For example, in my latest (unreleased) version of UsbMode I want the blinker to go on and off cleanly:
Code:
EpdController.setRegion("UsbMode", EpdController.Region.APP_3, blinker, EpdController.Wave.DU);
That's it, one line, no initialization.
The EpdController class was designed to handle such trivial uses.
Note: This jar itself has no functionality, all the method bodies are {}.
You will have to import android.hardware.EpdController
The 1.2 update uses a different EpdController and has a new EpdRegionParams.
This may or may not break code written for previous versions.
The best way to write code to use EpdController is to have it detect if there is no Epd
(i.e. for other devices), the old version or the new version.
Wrap a try/catch around a Class.forName("android.hardware.EpdController").
Wrap a try/catch around a Class.forName("android.hardware.EpdRegionParams").
The new epd.jar in the signature will allow you to compile without using redirection both the old and the new.
For details on the changes, see: http://forum.xda-developers.com/showpost.php?p=35390192&postcount=8
Bump & additional info.
By experimenting and reading documentation for other eInk controllers I've figured out the following:
Controllers support different algorithms for updating the pixels depending on the precision of the gray scale required and the compensation for previous ghosting.
On the Nook, we have the choice of waveform modes:
GC
GU (gray update)
DU (direct update)
A2
GL16
AUTO (auto selection of algorithm)
The screen can be divided up into regions where different algorithms may be used.
Some controllers support 15 regions, ours supports 8.
4 of these regions are earmarked for system usage, specifically:
Toast (popups)
Keyboard (soft keyboard layout)
Dialog (popups)
Overlay
The remaining 4 regions are left for the user.
Note: "HwRegion" is an enum for the complete 8 regions, "Region" is an enum for the 4 user regions.
An example: In my audio recorder I have two regions set aside for the VU bar graphs.
By setting these two regions to DU I get rid of update clutter and the response is quicker.
Currently, the EpdController in the Nook only operates with portrait coordinates.
If you wish to use this while in landscape mode you will have to rotate the coordinates first yourself.
It's sometimes hard to see exactly what/if some EPD setting is doing.
A good way to check it is to set a region for one half the width of whatever active graphic element you are trying to improve.
The difference can be very clear.
Renate NST said:
There seems to be very little actual documentation on the various eInk update modes.
Most of the information seems to have been extracted from working code.
Some of that code does not seem to be optimal in any case.
I'd like to start this thread on a discussion of the update modes.
You can look at all the code posted, but the bottom line is that eInk mode is configured by passing six discrete pieces of information to the EPD driver.
These six pieces may be wrapped up into a single static entity.
Name of entity requesting change (for logging purposes only)
Region, one of enumRegion[] (Region 4-7)
A rectangle, normally {0, 0, 600, 800}
Wave, one of enumWave[] (GC, GU, DU, A2, GL16, AUTO)
Mode, one of enumMode[] (INACTIVE, ACTIVE, ONESHOT, CLEAR, ACTIVE_ALL, ONESHOT_ALL, CLEAR_ALL)
Threshold, an int 1-15, only applies to A2 mode
A2 is the one bit, fast drawing method. It leaves ghosting behind.
In some applications, you would like to enable faster scrolling in A2 mode and then have it revert to "normal" upon completion.
I have an application with a full screen scroll.
After experimenting with the values, these two configs seem to do the job nicely.
Code:
configA2Enter = makeConfig(rpc, waveEnums[WAVE_A2], regionEnums[REGION_6], modeEnums[MODE_ACTIVE_ALL], THRESHOLD);
configA2Exit = makeConfig(rpc, waveEnums[WAVE_AUTO], regionEnums[REGION_6], modeEnums[MODE_ACTIVE_ALL], 0);
No user intervention is necessary, it scrolls quickly and redraws a clean image when done.
(A view.invalidate() is necessary after you invoke configA2Exit)
Does anybody have any further insight into these values or suggestions for improving them?
Click to expand...
Click to collapse
Excellent work! Do you happen to understand/can write up what the various fast mode/no refresh hacks do/how they use these different modes?
I've had X 'running' on my nook but only by triggering a full refresh every few seconds, and wondered how I could be more selective.
My reading of Norefresh was that it was doing something like parsing android log structures for areas that have changed.
Is there an easy way to trigger a refresh of part of the display from userspace, preferably directly on the driver or fb?
As for where the dithering is done, my guesswork is this is done by a blob running on the DSP module within the OMAP (which is perhaps the only interesting use of it I've seen).
Dave
Just done some playing writing directly to the entires in /sys/class/graphics/fb0 ; so for example:
echo -n 100,100,200,200,0,14 > epd_area
echo 2 > epd_refresh
causes the square 100,100->200,200 to be refreshed
the 14 being REGION(8)+CLEAR(4)+ONESHOT(2)
the 0 is wvfid+threshold*65536 I think.
I've put some code that runs under X to trigger updates; here (actually the comment is wrong, it's currently using oneshot+clear);
I never managed to get active to work.
http://forum.xda-developers.com/showthread.php?p=42393733#post42393733
Dave
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.
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