[Nexus 4 Original Android Development] _motley:
Setting custom RGB color settings via sysfs

This can be done from the adb shell on your PC, or any terminal app. If you change them, they will not persist after a reboot. However, you can set them in an init.d script if you found another color combination that you like better than the one I have used.

echo "255 255 255" > /sys/devices/platform/kcal_ctrl.0/kcal
echo 1 > /sys/devices/platform/kcal_ctrl.0/kcal_ctrl

Command 1 sets the color and Command 2 commits them. Stock is 255 255 255.

Setting custom Gamma settings via sysfs - Exp kernel build 31+ only - thanks to faux for sharing his code

Warning: changing these values can be potentially be dangerous to your display if you make a mistake. For those that feel comfortable with what they are doing and want to experiment, please report back and share your findings.

Important, please read!

There are ten digits in the string separated by one space

First digit is a checksum and is never stored. The checksum is simply the sum of the other 9 numbers. This is to make it harder to so the interface is respected and you are forced to think about what you are doing.

There are 3 sysfs interfaces for gamma, one for each color:

#!/system/bin/sh
# Show the current configuration and the checksum
cat /sys/devices/platform/mipi_lgit.1537/kgamma_red
cat /sys/devices/platform/mipi_lgit.1537/kgamma_green
cat /sys/devices/platform/mipi_lgit.1537/kgamma_blue

Update:

Recently molesarecoming started opening this up and showing us what the values can be used to adjust. Franco then suggested that the white and grays should be swapped in moles original work. So, for init.d values using this interface, we have the following "banks" if values if we agree with Franco on the swap of the whites and grays.

R: checksum, g_white, g_mids, g_black, 0, g_contrast, g_brightness, g_saturation, g_grey, 2
G: checksum, g_white, g_mids, g_black, 0, g_contrast, g_brightness, g_saturation, g_grey, 2
B: checksum, g_white, g_mids, g_black, 0, g_contrast, g_brightness, g_saturation, g_grey, 2

(the zero in position 5's and the 2's in position 10 are recommended to be left alone since they are currently unknowns)

Minus the checksum, the 27 values mirror the 3 color arrays (3 x 9 = 27) in the actual LG LCD driver. Minus the unknowns, we are left with 21 values. Note that every one of the variables can have their value tweaked by color (saturation for red, saturation for green etc.), however, it is recommended that you start with all the values of one type being the same and then tweak from there if you really want to fine tune.

You have a lot of power in your hands even without fine tuning. Many will argue that fine tuning isn't required. If you look at the stock settings by Google in post 2, they took advantage of fine tuning for whatever reason. Even though many don't like these settings by Google, it shows how flexible the interface can be.

Instructions:

1) Start with a preset config (LG or Google) as shown further below. This is a set of 3 lines, 10 numbers for each line.

2) Tweak columns for their values as above. For example, we tweak contrast and brightness as in faux's original app. We could also do the same for saturation, blacks, whites, grays etc.

Example: start with LG presets with numbers to adjust:

383 114 21 118 0 10 4 80 48 2

383 114 21 118 0 7 4 80 48 2

383 114 21 118 0 5 1 80 48 2

3) Now update the checksum in column 1 (first digit = sum of last 9 digits)

397 114 21 118 0 10 4 80 48 2

394 114 21 118 0 7 4 80 48 2

389 114 21 118 0 5 1 80 48 2

4) Create a script inside a text file - my recommendation for your first test

#!/system/bin/sh
# Set data color pro presets from shared Google spreadsheet (thanks user acer73!)
# Use LG presents as your starting values and then adjust columns 6 & 7 from the spreadsheet
echo "397 114 21 118 0 10 4 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_red
echo "394 114 21 118 0 7 4 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_green
echo "389 114 21 118 0 5 1 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_blue

#Set the complimentary RGB values for this calibration
echo "248 248 248" > /sys/devices/platform/kcal_ctrl.0/kcal
echo 1 > /sys/devices/platform/kcal_ctrl.0/kcal_ctrl

5) Run the script (or you can echo each line manually to test from adb if you prefer).

6) Turn the screen off and on for the gamma change to take effect.

7) Check the dmesg output for any clues and to see the output of the result.

8) Place the script into your /system/etc/init.d/ folder (or equivalent) for a permanent color change!

Screen refresh (added in b37) - this should only be called by apps or scripts while adjusting and testing colors "live" with the motley or faux sysfs interface. It should NOT be implemented on startup via init.d or by apps since it will compete with the normal power on process.

echo 1 > /sys/devices/platform/mipi_lgit.1537/refresh_screen

Presets:

#!/system/bin/sh
# Set LG presets (motley stock) - i.e. popular partial revert of Google's tweaks just before release
echo "383 114 21 118 0 0 0 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_red
echo "383 114 21 118 0 0 0 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_green
echo "383 114 21 118 0 0 0 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_blue

#!/system/bin/sh
# Set stock Google presets (from kernel source code)
echo "332 64 68 118 1 0 0 48 32 1" > /sys/devices/platform/mipi_lgit.1537/kgamma_red
echo "332 64 68 118 1 0 0 48 32 1" > /sys/devices/platform/mipi_lgit.1537/kgamma_green
echo "364 32 35 116 0 31 16 80 51 3" > /sys/devices/platform/mipi_lgit.1537/kgamma_blue

#!/system/bin/sh
# Set faux Google presets (not sure why his numbers differ)
echo "460 64 68 118 1 32 96 48 32 1" > /sys/devices/platform/mipi_lgit.1537/kgamma_red
echo "461 64 68 118 1 33 96 48 32 1" > /sys/devices/platform/mipi_lgit.1537/kgamma_green
echo "445 32 35 116 0 32 96 80 51 3" > /sys/devices/platform/mipi_lgit.1537/kgamma_blue

Spreadsheet with shared settings

https://docs.google.com/spreadsheet/ccc?key=0AoDp2qRui0u0dGE4T2gtSDBTRHVFSldPS2RrX1Rya0E#gid=0

FSYNC Control

Notes: I thought about combining these options, but many kernel apps already support these two options. So, I have them both and they can be controlled in combination to give us the 3 modes. If you set fsync_enabled = 0 it will be OFF regardless of how Dyn_fsync_active is set.

3 Modes:

Dynamic (default in b35 and higher)- fsync is asynchronous when screen is on, when screen is off it is committed synchronously

dynamic fsync ON

fsync ON

echo 1 > /sys/kernel/dyn_fsync/Dyn_fsync_active
echo 1 > /sys/class/misc/fsynccontrol/fsync_enabled

Off (best performance, less safe) - fsync is always asynchronous (b32 and prior builds)

dynamic fsync OFF

fsync OFF

echo 0 > /sys/kernel/dyn_fsync/Dyn_fsync_active
echo 0 > /sys/class/misc/fsynccontrol/fsync_enabled

Stock (safest) - fsync is always committed synchronously

dynamic fsync OFF

fsync ON

echo 0 > /sys/kernel/dyn_fsync/Dyn_fsync_active
echo 1 > /sys/class/misc/fsynccontrol/fsync_enabled

There is a lot of info out there on fsync, that will not be discussed here. I have run fsync off on several devices for awhile now and haven't experienced any issues. If you are using a device that is not stable and crashes alot, I recommend enabling it via init.d or script manager on boot. Hopefully your N4 is as stable as is mine.

USB Force Fast Charge

You can turn it on with popular apps (like Trickster MOD) that support the common sysfs toggle as shown below.

If you don't like it or don't want to use it, it is off by default.

Turn ON:

echo 1 > /sys/kernel/fast_charge/force_fast_charge

Turn OFF:

echo 0 > /sys/kernel/fast_charge/force_fast_charge

Notes:

When it is ON, you will not be able to connect your phone to your PC (adb, mtp etc.). This is expected behavior.

To start charging: turn fast charge ON, plug the USB cable into your PC, and charge up.

To stop charging: unplug the USB cable and turn fast charge OFF. Now you can plug back into your PC for normal trickle charging, adb/mtp etc.

Tip: if you see it connect to your PC (media device or adb), it isn't working. Unplug the cable, wait a couple seconds and plug it in again.

Boostpulse control - Experimental build only

Trickster MOD works great to play with these.

How long does it boost when Android senses touch? (in b10 and b14 it is above_hispeed_delay)

/sys/devices/system/cpu/cpufreq/interactive/boostpulse_duration

What freq does it boost to?

/sys/devices/system/cpu/cpufreq/interactive/hispeed_freq

Turn touchboost OFF/ON (in b10 and b14 only)

/sys/devices/system/cpu/cpufreq/interactive/input_boost

Thermal Throttling and Hotplug Control - Experimental build only

Warning: these do not have to be changed from the defaults and could potentially be dangerous if you make a mistake. For those that know what they are doing and want to experiment with settings, scripts etc. please report back your findings.

msm_thermal:

Throttle temp in C. Default is 70, valid range is 45 to 80 (recommend to not go over 75):

/sys/module/msm_thermal/parameters/throttle_temp

Minimum freq used in throttle down before returning to max, default is 7 = 1.13GHz. Range is 4 to 8 (810Mhz to 1.24GHz)

This is the index in the frequency table as seen in Trickster MOD, System Tuner etc. It is zero based (i.e. 304MHz is zero).

/sys/module/msm_thermal/parameters/min_freq_index

Turn on thermal debugging so you can see what is happening in the kernel log:

/sys/module/msm_thermal/parameters/thermal_debug

auto_hotplug:

Load based hotplugging parameters. I have taken _thalamus' base (thanks!) and have exposed most of the tuning parameters to userspace.

Turn off/on hot_plug debugging Y/N, default N, this spams the kernel log like crazy, turn on only when troubleshooting/testing

/sys/module/auto_hotplug/parameters/debug

Load at which a CPU is taken offline, 40-125, default 80:

/sys/module/auto_hotplug/parameters/disable_load_threshold

Load at which an extra CPU is put online, 130-250, default 200:

/sys/module/auto_hotplug/parameters/enable_load_threshold

Load at which all CPU's are enabled, 270-550, default is 400 (or 100 x number of cores):

/sys/module/auto_hotplug/parameters/enable_all_load_threshold

Sample rate in milliseconds, converted to jiffies at runtime, 10-50ms, default 20:

/sys/module/auto_hotplug/parameters/min_sampling_rate

Number of samples in the circular buffer, 5-50, default 10 (more samples = less aggressive; less samples = more aggressive):

/sys/module/auto_hotplug/parameters/sampling_periods

Maximum number of cores online (regardless of load) when screen is on, 1-4, default 4 (tune down for battery savings):

/sys/module/auto_hotplug/parameters/max_online_cpus

Minimum number of cores online (regardless of load) when screen is on, 1-4, default 1 (tune up for performance/bench-marking):

/sys/module/auto_hotplug/parameters/min_online_cpus

Vibration Intensity

You can also use Trickster MOD to set this.

Example increase intensity:

echo "90" > /sys/class/timed_output/vibrator/amp

To go back to stock:

echo "70" > /sys/class/timed_output/vibrator/amp

Why are the base voltage tables different on some phones

What CPU do you have? Nominal, Fast, Faster :)...or Slow:(

The phones with the lower default voltage values use the "fast" or "faster" frequency table, consider yourself lucky. This explains why some can't UV as much as others since they are starting with lower mV's to start. These are built in factory tolerances that depend upon the binning of your chip. I am familiar with the same thing in the tegra3 world where I have had more experience. So, don't worry as this is commonly done in this industry. Hopefully folks don't go freaking out because they have a nominal chip like I do:). It's probably good for a dev to have a nominal chip so we can better honor the limits.

http://en.wikipedia.org/wiki/Product_binning

How do I tell what I have?

If you boot up your phone fresh and look at the dmesg output (kernel log) while the messages are still there, you will find one of the following output messages where it selects it's frequency plan depending on the binning of the chip.

adb shell dmesg | grep PVS

acpuclk-8064 acpuclk-8064: ACPU PVS: Nominal

-or-

acpuclk-8064 acpuclk-8064: ACPU PVS: Fast

-or-

acpuclk-8064 acpuclk-8064: ACPU PVS: Faster

-or-

acpuclk-8064 acpuclk-8064: ACPU PVS: Slow

I have tweaked all the frequency tables nominal, fast, and faster (as well as slow to compensate for the lower freq) to keep them similarly scaled relative to stock. If you don't like the safe defaults (already UV'ed), then use voltage control and come up with your own preferred values.