[SCRIPTS] OC/UV for DEVIL2, AGNI and Nadia kernels (V7, V8 for Nadia) [2014-07-19]

Due to popular demand and to finally stop spamming DerTeufel thread I have decided to create a separate one for all things concerning Overclocking and Undervolting of his great kernel.
Agni kernel also has it's own set of scripts in post 2
Now also Nadia version is available - it's work in progress due to new functions being added to the kernel.
Here you will find scripts, guides, tools and information on how to test and find most stable settings for your phone while getting the most performance or battery life out of it.
In separate section you will find info on Governors and Schedulers and an explanation on why I choose those particular ones in my scripts.
It is the first such a thread I attempt to create so bear that in mind, also the amount of info I plan to include is large so it will take time to complete

If you have questions about why your colors have changed sound is louder or about charging battery speed, look in post #3 - there are explanations for it all. If you want to know more, ask and I will try to explain


Important stuff:
- scripts works on all versions of Devil2 kernel, that means 2.0+, they may work on lower versions but I have not tested it (and have no way to do that) so I welcome info if they do.
- scripts may work on other kernels as far as OC/UV stuff and general configuration, but specific stuff concerning battery charging, sound and screen config may not work because other kernels may not have specific options built in or use different config variables.
- from 05 april 2014 Agni kernel has it's own set of scripts (they were tested ONLY on TW version of Agni, I do not know if they will work on CM version - please report if you can)
- from 16 may 2014 Nadia kernel is officially supported
- scripts will work in part on Samsung and AOSP/CM to the point they may not include OC/UV capabilities and or governors/schedulers

SCRIPTS
GUIDES
GOVERNORS
SCHEDULERS

Here are the links to latest Devil 2 Kernels and Recoveries (hopefully they will be always up to date) - not compatible with KitKat (4.4.2 or higher)
N7100 (3G - t03g) - kernel 3.4_0.1.4 and recovery. Older 2.4.6 kernel can be downloaded HERE.
N7105 (LTE - t0lte) - kernel 3.4_0.1.4 and recovery. Older 2.4.5b kernel can be downloaded HERE.
Latest Agni pureSTOCK kernel HERE
Latest Nadia kernels can be obtained HERE

As for testing stability and general behavior of my scripts, here are some tools to accomplish that:
CPUTableau - displays active cores and frequencies in a small floating window
Stability Test - use to test stability of overclock both CPU and GPU or even combined, download HERE from Playstore (free)
Preferred Modem (MJ5) can be installed using Hurricane Modem Changer downloaded HERE
Preferred Bootloader (MJ5) can be downloaded HERE and installed using Odin (PC version only)
Preferred recovery (if you don't need f2fs) Philz 5.15 can be downloaded HERE (Odin version) or HERE (flashable in recovery)
The only recovery that supports f2fs is Devil Recovery (downloads above).
For all those that have lost root HERE you can obtain the latest Chainfire's SuperSU updates - it should fix any root problems.

Important tools to configure system for best stability prior to overclocking can be found HERE.

Here is my battery stats using 1920/666 high UV script:
- over 3 days
- almost 5 hours screen-on
- 13+ hours of music
- about 1 hour of call time
- data and gps off
- wifi on

PLEASE - if you are using any TW rom, find the way to disable DVFS (using Wanam Xposed - in Advanced settings for example) because it will cause problems with my UV scripts as they modify the same setting that Samsung modifies on the fly and DVFS WILL overwrite what I set in script.

Also before you Overclock / Undervolt:
For maximum stability I would suggest eliminating common "instability makers" in our phones. It is best to combine bootloaders, modems and system software from the same release. For N7100 users I suggest upgrading bootloader to MJ5 as it grants use of WiFi without any patches while being "downgrade friendly" meaning you can downgrade to TW 4.1.2 without KNOX hassle.
Along with this, MJ5 modem works great in most of Europe, Phoenix 16.7 while from ML3 release still works great with that combination. With that combination, you will have the most stable base to start overclocking / undervolting experience - aside from OC/UV experiments I have not had any FC or freeze for close to a month now. Now as for the KK roms, only newer Agni and Nadia kernels support this system, they are compatible with MJ5 bootloader (downgrade friendly) or ND3 (if you don't care about KNOX and want to charge battery with phone off).

The latest version of my scripts is V7 (V8 for Nadia).

And the screenshots of what performance you can expect out of my scripts (made with 1920_733_highUV script)



Here are the results of UV combined with ABB manipulations - up to 12 hours on 1% of battery - night time idle use.



Quick changelog for V7:
- split the script into 2 parts (S99mat9v and T99mat9v) to correctly apply all undervolting settings, they weren't before
- changed caching to compressed zswap
- modified system cache pressure (swappiness)
- set SD memory cache smaller as all test indicate that FIOPS scheduler perform better with that setting
- undervolting and stability of the scripts should be much better now because all my settings are correctly recognized by system
- preliminary work done for future support for Agni kernel

Quick changelog for Nadia V8 scripts:
- changed audio engine config to follow kernel changes (boeffla to wolfson)
- reenabled touchboost (since kernel supports it)
- changed ABB and voltage settings for longer battery life
- scripts now work correctly with latest kernel releases (support for 2Ghz added in scripts)

For all those searching for ultra smooth experience at the cost of some battery I have created additional ultra smooth addon. Available for download at the bottom of this post.

DISCLAIMER: Although it is of very low probability that the use of my scripts will result in broken hardware, it may so happen because any overclocking accelerates aging of CPU and may in time break said CPU (or GPU for that matter). I take no responsibility for that. Also remember to backup your data (and whole rom if possible) because too much overclocking and/or undervolting may result in data loss and errors on partitions that may make your system unbootable.

There is a flashable script that removes my OC/UV script from your system called "mat9v_overclock_remove", use it if you want to get rid of my meddling
Every script also deletes an old version of my script before flashing a new one so you can just flash one over the other to find a perfect one for you.
There are 4 flavors of them:
- geared for overclocking by any means necessary, fast performance while not caring about battery too much.
- middle ground of overclocking while taking care of battery.
- stock clocks and as much battery as possible while not letting performance suffer too much.
- battery by any means necessary, even if it impacts performance - no overclocking.

A little bit of terminology first so you can decipher the script name and find the one for you.
Low - low undervolting means less undervolting, worse battery life but better chance of stability - not every phone can tolerate a lot of UV.
Mid - medium undervolting.
High - high undervolting.
Max - maximum undervolting, best battery but many phones will not work with it.
OC and noOC - differentiates between versions with and without overclocking.
UC - underclocked - represents best battery at the cost of performance.
UV and noUV - this time between undervolting and no undervolting.
1200, 1600, 1800, 1920 and 2000 - these are CPU overclocking values.
400, 533, 666, 733 and 800 - these are GPU overclocking values.

Important - as I have an ASV1 phone, all scripts are optimized for this CPU quality run, as such I am unable to test stability of ASV 0, 2 and 3 phones (and they do differ a lot)
ASV version can be found by going to /sys/devices/system/abb and viewing the content of file abb_info
Based on that you can suspect the level of OC and UV your phone will be able to achieve.
ASV 0 being the worst - least OC potential and not a lot of UV
ASV 3 being the best - in most cases will take 2000Mhz and decent amount of UV

For reference - older script versions are in THIS POST

WARNING - max scripts have now even lower voltages so pleas if you used max script before and now it is not working, try high script before posting problems.

Below scripts are created for Devil kernel (Agni version is further below).

First - geared for battery with underclocking:

Script_UC_1200_400 - V7 - noUV.zip - special version created for stability reason without any undervolting.
Script_UC_1200_400 - V7 - low_UV.zip
Script_UC_1200_400 - V7 - mid_UV.zip
Script_UC_1200_400 - V7 - high_UV.zip
Script_UC_1200_400 - V7 - max_UV.zip

Second - still geared for battery but with standard clocks:

Script_noOC_1600_533 - V7 - noUV.zip - special version created for stability reason without any undervolting.
Script_noOC_1600_533 - V7 - low_UV.zip
Script_noOC_1600_533 - V7 - mid_UV.zip
Script_noOC_1600_533 - V7 - high_UV.zip
Script_noOC_1600_533 - V7 - max_UV.zip

Third - medium overclock on both CPU and GPU:

Script_OC_1800_666 - V7 - noUV.zip - special version created for stability reason without any undervolting.
Script_OC_1800_666 - V7 - low_UV.zip
Script_OC_1800_666 - V7 - mid_UV.zip
Script_OC_1800_666 - V7 - high_UV.zip
Script_OC_1800_666 - V7 - max_UV.zip

Fourth - medium overclock on CPU and high for GPU (for games?):

Script_OC_1800_733 - V7 - noUV.zip - special version created for stability reason without any undervolting.
Script_OC_1800_733 - V7 - low_UV.zip
Script_OC_1800_733 - V7 - mid_UV.zip
Script_OC_1800_733 - V7 - high_UV.zip
Script_OC_1800_733 - V7 - max_UV.zip

Fifth - By popular demand - strong CPU overclock without GPU overclock:

Script_OC_1920_533 - V7 - noUV.zip
Script_OC_1920_533 - V7 - low_UV.zip
Script_OC_1920_533 - V7 - mid_UV.zip
Script_OC_1920_533 - V7 - high_UV.zip
Script_OC_1920_533 - V7 - max_UV.zip

Sixth - strong overclock on CPU and medium on GPU (www and general use?):

Script_OC_1920_666 - V7 - noUV - special version created for stability reason without any undervolting.
Script_OC_1920_666 - V7 - low_UV.zip
Script_OC_1920_666 - V7 - mid_UV.zip
Script_OC_1920_666 - V7 - high_UV.zip
Script_OC_1920_666 - V7 - max_UV.zip

Seventh - strong overclock for both CPU and GPU - there will be no noUV version for this because frankly the phone will overheat so quickly without undervolting that on the whole it will be slower than with less overclocking:

Script_OC_1920_733 - V7 - low_UV.zip
Script_OC_1920_733 - V7 - mid_UV.zip
Script_OC_1920_733 - V7 - high_UV.zip
Script_OC_1920_733 - V7 - max_UV.zip

Eight - this last category is not for those faint of heart Maximum overclock and mid to max undervolt - there is no use overclocking that much if you can't ondervolt a lot because overheat protection will quickly force CPU to lower it's clock:

Script_OC_2000_733 - V7 - mid_UV.zip
Script_OC_2000_733 - V7 - high_UV.zip
Script_OC_2000_733 - V7 - max_UV.zip
Script_OC_2000_800 - V7 - mid_UV.zip
Script_OC_2000_800 - V7 - high_UV.zip
Script_OC_2000_800 - V7 - max_UV.zip


Below are scripts created for Agni kernel - they differ from Devil in functionality:
- first because Agni does not support FIOPS scheduler (SIO is used instead)
- second because Agni does not use compressed swap space (I have left it at default 512MB swap, but decreased swappiness from default)
- third because Agni support for color correction differs so much from Devil I had to recreate color settings - still they differ from Devil ones
- last, Agni support Boeffla sound but does not support ScoobyDoo sound so I had to "migrate" settings
- there are few other missing futures, for example touch led control does not work for me so it's missing from the script (maybe xposed is overwriting it somewhere)

First - geared for battery with underclocking:

Script_UC_1200_400 - V7 - noUV.zip - special version created for stability reason without any undervolting.
Script_UC_1200_400 - V7 - low_UV.zip
Script_UC_1200_400 - V7 - mid_UV.zip
Script_UC_1200_400 - V7 - high_UV.zip
Script_UC_1200_400 - V7 - max_UV.zip

Second - still geared for battery but with standard clocks:

Script_noOC_1600_533 - V7 - noUV.zip - special version created for stability reason without any undervolting.
Script_noOC_1600_533 - V7 - low_UV.zip
Script_noOC_1600_533 - V7 - mid_UV.zip
Script_noOC_1600_533 - V7 - high_UV.zip
Script_noOC_1600_533 - V7 - max_UV.zip

Third - medium overclock on both CPU and GPU:

Script_OC_1800_666 - V7 - noUV.zip - special version created for stability reason without any undervolting.
Script_OC_1800_666 - V7 - low_UV.zip
Script_OC_1800_666 - V7 - mid_UV.zip
Script_OC_1800_666 - V7 - high_UV.zip
Script_OC_1800_666 - V7 - max_UV.zip

Fourth - medium overclock on CPU and high for GPU (for games?):

Script_OC_1800_733 - V7 - noUV.zip - special version created for stability reason without any undervolting.
Script_OC_1800_733 - V7 - low_UV.zip
Script_OC_1800_733 - V7 - mid_UV.zip
Script_OC_1800_733 - V7 - high_UV.zip
Script_OC_1800_733 - V7 - max_UV.zip

Fifth - By popular demand - strong CPU overclock without GPU overclock:

Script_OC_1920_533 - V7 - noUV.zip
Script_OC_1920_533 - V7 - low_UV.zip
Script_OC_1920_533 - V7 - mid_UV.zip
Script_OC_1920_533 - V7 - high_UV.zip
Script_OC_1920_533 - V7 - max_UV.zip

Sixth - strong overclock on CPU and medium on GPU (www and general use?):

Script_OC_1920_666 - V7 - noUV - special version created for stability reason without any undervolting.
Script_OC_1920_666 - V7 - low_UV.zip
Script_OC_1920_666 - V7 - mid_UV.zip
Script_OC_1920_666 - V7 - high_UV.zip
Script_OC_1920_666 - V7 - max_UV.zip

Seventh - strong overclock for both CPU and GPU - there will be no noUV version for this because frankly the phone will overheat so quickly without undervolting that on the whole it will be slower than with less overclocking:

Script_OC_1920_733 - V7 - low_UV.zip
Script_OC_1920_733 - V7 - mid_UV.zip
Script_OC_1920_733 - V7 - high_UV.zip
Script_OC_1920_733 - V7 - max_UV.zip

Eight - this last category is not for those faint of heart Maximum overclock and mid to max undervolt - there is no use overclocking that much if you can't ondervolt a lot because overheat protection will quickly force CPU to lower it's clock:

Script_OC_2000_733 - V7 - mid_UV.zip
Script_OC_2000_733 - V7 - high_UV.zip
Script_OC_2000_733 - V7 - max_UV.zip
Script_OC_2000_800 - V7 - mid_UV.zip
Script_OC_2000_800 - V7 - high_UV.zip
Script_OC_2000_800 - V7 - max_UV.zip
Below are scripts created for Nadia kernel - for now they differ from others in functionality:
- first because Nadia does not support FIOPS scheduler (SIO is used instead)
- second because Nadia does not use compressed swap space
- third because Nadia currently does not support color correction
- Nadia supports Wolfson sound but directory structure is different
- there are few other missing futures, for example touch led control does not work, touchboost is working now
IMPORTANT: My scripts remove almost all Nadia configuration done in /etc/init.d so to fully remove/revert to original Nadia config you have to reflash Nadia kernel. Consequently, after flashing new Nadia kernel my scripts MUST be reflashed or they will not work correctly.

First - geared for battery with underclocking:

Script_UC_1200_440 - V8 - noUV.zip - special version created for stability reason without any undervolting.
Script_UC_1200_440 - V8 - low_UV.zip
Script_UC_1200_440 - V8 - mid_UV.zip
Script_UC_1200_440 - V8 - high_UV.zip
Script_UC_1200_440 - V8 - max_UV.zip

Second - still geared for battery but with standard clocks:

Script_noOC_1600_533 - V8 - noUV.zip - special version created for stability reason without any undervolting.
Script_noOC_1600_533 - V8 - low_UV.zip
Script_noOC_1600_533 - V8 - mid_UV.zip
Script_noOC_1600_533 - V8 - high_UV.zip
Script_noOC_1600_533 - V8 - max_UV.zip

Third - medium overclock on both CPU and medium to none on GPU:

Script_OC_1800_666 - V8 - noUV.zip - special version created for stability reason without any undervolting.
Script_OC_1800_666 - V8 - low_UV.zip
Script_OC_1800_666 - V8 - mid_UV.zip
Script_OC_1800_666 - V8 - high_UV.zip
Script_OC_1800_666 - V8 - max_UV.zip
Script_OC_1800_533 - V8 - low_UV.zip
Script_OC_1800_533 - V8 - high_UV.zip
Script_OC_1800_533 - V8 - mid_UV.zip


Fourth - medium overclock on CPU and high for GPU (for games?):

Script_OC_1800_733 - V8 - noUV.zip - special version created for stability reason without any undervolting.
Script_OC_1800_733 - V8 - low_UV.zip
Script_OC_1800_733 - V8 - mid_UV.zip
Script_OC_1800_733 - V8 - high_UV.zip
Script_OC_1800_733 - V8 - max_UV.zip

Fifth - By popular demand - strong CPU overclock without GPU overclock:

Script_OC_1920_533 - V8 - noUV.zip
Script_OC_1920_533 - V8 - low_UV.zip
Script_OC_1920_533 - V8 - mid_UV.zip
Script_OC_1920_533 - V8 - high_UV.zip
Script_OC_1920_533 - V8 - max_UV.zip

Sixth - strong overclock on CPU and medium on GPU (www and general use?):

Script_OC_1920_666 - V8 - noUV - special version created for stability reason without any undervolting.
Script_OC_1920_666 - V8 - low_UV.zip
Script_OC_1920_666 - V8 - mid_UV.zip
Script_OC_1920_666 - V8 - high_UV.zip
Script_OC_1920_666 - V8 - max_UV.zip

Seventh - strong overclock for both CPU and GPU - there will be no noUV version for this because frankly the phone will overheat so quickly without undervolting that on the whole it will be slower than with less overclocking:

Script_OC_1920_733 - V8 - low_UV.zip
Script_OC_1920_733 - V8 - mid_UV.zip
Script_OC_1920_733 - V8 - high_UV.zip
Script_OC_1920_733 - V8 - max_UV.zip


The last script removes my meddling from your system for Devil, Agni and Nadia kernels - new for V7 and V8 versions, remember to re download !!
Overclock_remove.
Ultrasmooth addon remove.

The scripts below MUST be used in addition to my OC scripts above as they only modify governor settings and do not change anything else.

Ultrasmooth script for those using my scripts versions 1200 or 1600Mhz.
Ultrasmooth script for those using my scripts versions 1800 and above.

If for some reason the scripts are not working, meaning there are no changes in maximum CPU speed, sound and color remains the same and so on, it may be possible you are one of the unlucky ones that have a rom that does not correctly execute scripts in /etc/init.d on system startup. In that case your only recourse is to use some app that can execute scripts independent from rom capabilities - fortunately there is such an app in Playstore called SManager. Here is a quick guide on how to use it to start my scripts:

1. Install app
2. Start it.
3. Select to "Browse as root" and grant root access
4. Navigate to /etc/init.d
5. Tap on S99mat9v script
6. Tap on "Su" icon to have it "light up"
7. Tap "Run"
8. Wait about 30 seconds for script output
9. Tap little grey "x" at the top
10. Tap T99mat9v and repeat steps from previous script
11. If present and if you want to do the same with U99mat9v

After few hours of testing and if everything works well, you can also tap on "Boot" icon from step 6
Thats all. If after executing any script the system freezes just reboot and maybe flash some other script version (freezing means your hardware can't cope with that script level).

First - the guide for EXT4 to F2FS migration

OK, here is a simple guide to doing it SAFELY (if not simply)
1. To get full benefits of F2FS every partition except external sdcard should be formatted.
2. Copy ALL your personal data from INTERNAL sdcard to either your external one or to your pc
3. Make space on your EXTERNAL sdcard for full backup of system and data of your current running system
4. That should be about 4GB in most cases, recovery will inform you how much space is required for backup when you attempt to start it, the best chance to have no problems would be to have about 8GB free on external sdcard
5. Download new recovery and kernel from OP of this thread.
------- here starts somewhat destructive part ---------------
IMPORTANT - all new recoveries based on v6.0.+ have a curious problem, the first time you try to access external sdcard it bouces you to the main menu of recovery, following access attempts are without problem, unless you reboot recovery, then the problem occurs again. I suspect it's due to mounting external sdcard for use on the first attempt
6. Boot into recovery.
- flash your new recovery
- reboot recovery (option to do that is found in Power Options>Reboot Recovery)
- once back in recovery flash new kernel
- reboot recovery again
- go to Backup and Restore > Custom Backup and Restore > Custom Backup Job
- there select : boot, recovery, system, data and cache and tap Start Custom Backup Job
- select (Important): Backup to /storage/sdcard1
The backup will take time, for me it took 18 minutes to complete (4GB) and it may look like it has frozen, especially when creating MD5 - be patient
- once completed go back to main menu
- enter Mounts and Storage
- format /system and from submenu select f2fs
- format /data, /sdcard and secondrom (it will destroy your secondary rom as it is placed in /sdcard so BACKUP it before) and select f2fs from submenu
- format /cache - you will not have an option to select f2fs (it's not even strictly necessary to format as all /cache data are placed in /data partition and since /data is formatted to f2fs......)
- go back to main recovery menu
- tap Backup and Restore
- tap Restore from /storage/sdcard1
- select freshly made backup (the date is obvious)
- wait for some time being good patient person you are
- go back to main recovery menu
- tap reboot primary system now
7. You should have a fully working system now, it's time to restore your personal data from step 2 to internal sdcard
Process finished.

Second - guide to modifying various cool and useful settings in the kernel (under construction).

Devil 2 kernel let's us play with a lot of exciting futures, the most interesting being increased battery charging, ScoobyDoo sound engine and advanced color correction and enhancement. Here I will try to guide you in how to configure those settings so you can get the most out of your hardware.

1. Battery charging.
Modifying these values CAN be dangerous to your hardware, both phone, charger and PC (if you are charging from USB port) but should not pose any problems if there are no hidden problems with charging equipment. Samsung installed in our phones an intelligent charging controller that constantly monitors charging current looking for spikes and other problems. Unfortunately it is very sensitive. As the charger ages and cable is constantly bent, connectors plugged and unplugged, they physically loose quality of connection, creating instabilities in charging current. The controller reacts to that by first lowering current requested from charger until it passes quality checks, but checks are so strict that often we end up with charging of 8-10 hours instead of 2.5 as it should be. The charger is able to supply 2A of constant current, but our battery (3100mAh) will not be charged that fast unless we turn our phone off because when it is running it still uses some power, right? This brings us to the configuration of charging circuitry - we have 3 separately defined charging sources - AC charger, USB charger and specialized charging USB port, each has defined total input power and max amount of current for charging battery.
In my scripts I have configured the following values:
The first pair is used to define parameters for charging from AC charger, total input power and the part for charging battery, both are increased from default but should make no problem for standard Samsung charger (as a side note, default config does not even use full 2A current, but only 1.8A)
echo "2100" > /sys/devices/platform/samsung-battery/dcp_ac_input_curr
echo "2000" > /sys/devices/platform/samsung-battery/dcp_ac_chrg_curr
Second pair defines charging from USB port - now this one is more risky because the USB 2.0 standard defines max current available as only 500mA while in fact almost all newer mainboards easily provide much more power (my own works with 2A without problem - or maybe it did not suffer cataclysmic burnout yet). If you have a new PC you should be safe, if not - the correct settings is 500/500 in both entries.
echo "1300" > /sys/devices/platform/samsung-battery/sdp_input_curr
echo "1200" > /sys/devices/platform/samsung-battery/sdp_chrg_curr
The last pair defines specialized charging port - I have no such port to test so I did not increase the values a lot, those should be perfectly safe.
echo "1350" > /sys/devices/platform/samsung-battery/cdp_input_curr
echo "1250" > /sys/devices/platform/samsung-battery/cdp_chrg_curr
This value is important if you ever use non-standard battery. Samsung 3100mAh battery has the maximum charging limit of 4.35V and as you see I have lowered that limit to 4.3V - while it will decrease battery max capacity by about 100mAh it will increase how many times the battery can be safely charged before it degrades. If anyone is very interested in how process works please read HERE
echo "4300000" > /sys/devices/platform/samsung-battery/batt_chrg_soft_volt
Last two entries are very important to charging speed. The first disables 100mA charging current margin that always lowers max charging speed by 100mA from max defined by detected current quality. The second completely disables mechanism responsible for detecting quality of charging current. This is a dangerous process that MAY cause your charger and phone to spontaneously combust if your battery and/or charger is faulty. Haven't heard of it ever happening but there is always the first time Consider also that other phones do not have that circuitry.
echo "1" > /sys/devices/platform/samsung-battery/ignore_stable_margin
echo "1" > /sys/devices/platform/samsung-battery/ignore_unstable_power

2. ScoobyDoo sound system is used to configure quality of sound output from our phone. There is a lot of things that can be done, including sound processing and 3D audio postprocessing but I personally like to hear sound as close to the recorded source so the only thing I did in my script is disable all sound processing and slightly increase amplifier boost value because my headphones are quite demanding.
echo "1" > /sys/devices/virtual/misc/scoobydoo_sound/fll_tuning
echo "1" > /sys/devices/virtual/misc/scoobydoo_sound/dac_osr128
echo "1" > /sys/devices/virtual/misc/scoobydoo_sound/adc_osr128
echo "1" > /sys/devices/virtual/misc/scoobydoo_sound/dac_direct
echo "1" > /sys/devices/virtual/misc/scoobydoo_sound_control/enable
echo "57" > /sys/devices/virtual/misc/scoobydoo_sound/headphone_amplifier_level

"dac_osr128" and "adc_osr128" improves sound quality by applying 128X oversampling - improves clarity
"dac_direct" forces the bypass of analog channel conversion
"fll_tuning" tunes audio chip clock, reduces distortion by playing with power supplied to headphones
"enable" well, enables control of audio chip by this engine
"headphone_amplifier_level" changes max volume for headphones, max value here being 63 but it can produce distortions so better to use something lower

Here are 3 settings for modifying Speaker configuration to increase or decrease total loudness (personally don't use that but maybe someone may need it)
echo "0" > /sys/devices/virtual/misc/scoobydoo_sound/speaker_tuning
echo "44" > /sys/devices/virtual/misc/scoobydoo_sound/speaker_tuning_level
echo "0" > /sys/devices/virtual/misc/scoobydoo_sound/speaker_offset

The first one enables Speaker control, change to "1" to enable.
Second increases speaker volume, default being 44 with max value of 63, change to your liking
Third does similar thing but changes "base" speaker volume value, default being 0, why it exist and in what way it differs from speaker_tuning I don't know

There is a few other settings here:
Stereo expansion - creates 3D sound from stereo source
Speaker amplification - does the same as Headphone amplification only for phone speaker - I would not touch that even wit 10 feet pole, the built in speaker just don't have the quality to reproduce anything louder
Equalizer - 5 band one to tune the sound for various headphones? Never used that one, don't like equalizers
Substitute "1" with "0" in those entries to disable my modifications.

3. Samsung loves to market "crisp and lifelike colors", yeah right. They may look good but have no base in reality More than a year ago someone (don't remember who, search in Perseus kernel thread) did test our display with hardware tester to tune the color gamut to as close as possible reproduce natural colors. The effect we can see when the factory color settings are enabled without Samsung "improvements" There is a lot that can be done within this engine but I have done only the minimum to correct color to it's base form.

echo "1" > /sys/class/misc/mdnie/hook_intercept
echo "1" > /sys/class/misc/mdnie/sequence_intercept
echo "1" > /sys/class/misc/mdnie/hook_control/s_MCM

Above that, you can enable Dogital Noise Reduction for both Video and Desktop image, force HDR, modify Gamma for each color or combined, enable Dithering and Edge Enhancement, play with color temperature, enable Adaptive Brightness and much more. I have not found any documentation on what exactly can be done, not even correct values that can be passed to various settings. If anyone have such a document available I welcome any links
Substitute "1" with "0" in those entries to disable my modifications.

4. In Devil kernel touch buttons backlight can be controlled by rom or the kernel. In my script I have completely disabled backlight for the buttons. After all there are only two of them and their placement is kind of in the center , at night they are very bright and annoying.

echo "1" > /sys/class/sec/sec_touchkey/touch_led_handling
Enable touch led handling by kernel.
echo "1" > /sys/class/sec/sec_touchkey/touch_led_on_screen_touch
Not really needed but turns on leds when you touch the screen.
echo "1" > /sys/class/sec/sec_touchkey/force_disable
This one disables the leds completely.

You can also modify sensitivity of touchkey, how long the leds are alight after touching screen or touchkey, you can change led brightness.
Substitute "1" with "0" in those entries to disable my modifications.

5. Latest version of Devil kernel implement F2FS file system. Created by Samsung (Jaegeuk Kim) in 2012 and designed specifically for flash based drives. F2FS belongs to a class of file systems named Long-structured File system, it's main design principles can be described in following: "A log-structured file system writes all modifications to disk sequentially in a log-like structure, thereby speeding up both file writing and crash recovery. The log is the only structure on disk; it contains indexing information so that files can be read back from the log efficiently. In order to maintain large free areas on disk for fast writing, the log is devided into segments and use a segment cleaner to compress the live information from heavily fragmented segments". Main advantages lie in increased write performance (which is an Achilles heel of flash solutions) in random write category (but not only that). It is an answer to logging problems in ext4 and earlier file systems. Has internal garbage collector and both "on demand" and "background" cleaning service. Test performed by Anandtech show almost 100% increase in random write performance with small increase in write and read performance compared to ext4 filesystem (phones used were Motorola Moto X vs Galaxy S4). In all a highly suggested solution for us

Let's begin with LULZACTIVEQ governor as it is the one I have chosen to use for my scripts. This governor was created by @robertobsc by modifying lulzactive governor for use in Galaxy S2 and S3 phones, from the mouth (so to speak) of the creator more info can be found HERE.
Lulzactive is based on interactive governor with "hotplugging logic built in". It has a lot of configuration options and while that may suggest it has a lot of variables to check while making any decision it really is not that complicated. Some other governors just make decisions without any possible input from the user with some values hard coded, so not much is changed in terms of overhead.
Generally this governor works the following way:
- periodically check the cpu load
- based on that decide if increase in frequency is needed ("inc_cpu_load" defines at what cpu load level frequency should be increased) or maybe decrease is better at the moment (defined in "dec_cpu_load")
- here comes hotplug part
- if the frequency is high enough ("hotplug_freq_1_1" to "hotplug_freq_3_1" set levels at which next core is brought online) additional cores are powered up and the load is shared between them if possible (multithreading) or maybe powered down if the frequency falls below certain value (decided by "hotplug_freq_2_0" to "hotplug_freq_4_0")
- on top of that the core will not be brought online if "queue length" is not long enough - queue length is a value that tells how many things must be waiting to be processed to meet the condition - they are defined in "hotplug_rq_1_1" to "hotplug_rq_3_1" for conditions to enable cores 2-4 and in "hotplug_rq_2_0" to "hotplug_rq_4_0" for conditions to disable cores 2-4
- "pump_up_step" decides how high to jump on detecting the need to increase frequency - it defines how smooth should the increasing the frequency be happening
- "pump_down_step" in mirror decides how much to decrease frequency if there is not enough load
- "hispeed_freq" is a special setting that comes into effect if very big loads are detected as in for example starting benchmark - it enables cpu to jump directly to the defined frequency, for me it is a max frequency for the script class - max frequency the cpu is allowed to run at all - this option is the main culprit in stability problems with undervolting because it causes the biggest spikes in voltage when changing frequencies from say 200Mhz straight to 1920Mhz - change that to 1000Mhz and you probably can jump another UV step
- "screen_off_max_step" - decides what is the max frequency the cpu can work at when screen is off

There are many other settings that are user configurable, but frankly I can't measure their impact on battery and their impact on smoothness is too hard to detect so I leave them alone.
For example "hotplug_sampling_rate" decides how often to check if maybe cores should be brought online or turned off - it can create some problems because constant turning cores on and off costs battery, much more then keeping them idle for a moment longer in case they are needed.

My governor config differs quite a lot from defaults and here is why I have it configured like that:
- I prefer highly reactive config meaning when the load is detected I jump to higher frequency quickly to deal with load (by 5 steps, from 200 to 700Mhz) while normal config would go from 200 to 400 to 600 - those two ways of doing things are based on assumption that most load situations can be dealt with with small increase in frequency or (my way) they can not and require more speed to take care of things. Standard way would have you going up slow and turning next core quite quickly, I on the other hand jump to 700Mhz to deal with load and if it's not enough go to 1200Mhz (at 1200Mhz it is possible to have all 4 cores enabled as decided by "hotplug_freq_3_1" if there is enough work to do - decided by "queue_length"). That way is battery friendly as it mostly uses one core to deal with load and only turns on additional cores when really required - it has one caveat though as sometimes user interface may be a little jumpy when in addition to doing something like sliding or changing desktop pages an app is starting or updating in the background. For those that feel this jumpiness and it's annoying I have created "ultrasmooth" script addon that relaxes those settings in enabling additional cores to start sooner.
Normally it works like this:
Depending on script version, on normal load (over 60% at current frequency), the speed jumps up 5 grades - from 200Mhz to 700Mhz, if load is still exceeding 60%, jumps again to 1200Mhz and again to 1700Mhz. If first jump is not enough to deal with load and jump to 1200 is executed, second, third and fourth cores are powered up (that also require a certain queue length to be filled before they come online and ensures that short bursts of load do not needlessly power up additional cores). Basically on initial load - from 200-300Mhz - I'm turning cores later than in default config, because it happens once the frequency reaches 3rd hop (1200Mhz).
Consequently, my script asks for swift clock down of the cpu. From current maximum go down 4 steps if utilization is below 50%, then next 4 steps, test again, next 4 steps - along the line cores are turned off.
In ultrasmooth version:
Start at 200Mhz, on detected load jump to 700Mhz (at 700Mhz it is allowed to have 2nd core turned on if queue_length is met), if required again jump to 1200Mhz (by that time both 3rd and 4th core can be enabled if queue_length requirements are met). Now that all cores are powered up we can jump to 1700Mhz and higher if required. Clocking down works as in original, only cores are powered down later, else the settings would interfere with powering up sequence.

Other governors information will come later when I have a time to work on that (I do not want to copy and paste without knowing what I'm talking about).

Reserved for Schedulers

synapsesboob said:

mat9v I was wondering if you could include some of your versions with the saturated colors for those that devilishly prefer it. I saved your post about doing the edits but thought maybe a ready made flashable version may be helpful to those like me.

Sent from my SCH-I605 using Tapatalk

Click to expand...

Click to collapse

You know, this is a simple edit, but to do it for all my script versions would be hell. In V6 there will be probably more then 30 scripts

izz.amizan said:

here is my attempt and result...

1st attempt, flashed noOC 1600 533 max UV v5, result phone freeze

2nd, flashed noOC 1600 533 high UV v5, result good n responsive

3rd, flashed OC 1800 666 high UV v5, result phone freeze...

4th, flashed OC 1800 666 v5 low UV, result phone feeeze

5th attempts, flash OC 1800 666 high UV v6, result phone feeeze...

now, im on noOC 1600 533 high UV v6... everything is smooth, responsive n no freezing at all...

I'd like to test OC 1800 but even the low UV setting gave me a frozen phone result... im very sad...

kernel devil 2.4.6 (also tried on 2.3.2)
rom phoenix 16.7 (both odex n deodex gave me the same result)

Click to expand...

Click to collapse

Well, you could try noUV version to test if overclocking on your particular phone will work at all...