[Research] OSS Chroma Service - Razer Phone 2 ROMs, Kernels, Recoveries, & Other D

[Research] OSS Chroma Service - Razer Phone 2 ROMs, Kernels, Recoveries, & Other D

As the light up logo on the back of the Razer Phone 2 is one of its most striking features, I felt it was a good idea to get some documentation going on what makes it tick and open the way for possibly using the logo for our own effects. I'll expand this thread as time goes on. My ultimate goal would be to develop an OSS alternative to the stock Chroma service which would not only enhance the stock ROM's implementation, but open the way for the logo to be used on custom ROMs and GSIs when those are available.
Physical:
The logo consists of a total of 9 coloured LEDs.
There are 3 diffuser pads on a flexible PCB.
Each pad contains a red, green and blue LED.
Each pad diffuses the light from the LED into roughly the shape of a portion of the Razer logo.
The pads are roughly centered on each of the three "snake heads"
The entire PCB is covered by a third, larger, diffuser pad. It's actually unclear which of the pads (the 3 individual or the single big pad) are actually responsible for shaping the light into the rough logo shape. It is clear however that the light is diffused into a specific shape and not a general area. (Razer clearly has experience )
Controller:
The 9 LEDs are controlled by a Texas Instruments LP5523 9-channel LED programmable controller chip.
The chip has mainline kernel drivers. The Razer phone 2 kernel has additions to these drivers by Razer to allow faster loading of microcode by bypassing the kernel firmware interface.
The 9 LEDs can be controlled through standard sysfs properties (thanks to Razer's additions), or microcode can be uploaded to the controller through the kernel firmware interface.
The controller chip has it's own microcode program banks and can run the animations without interrupting the main processor. This means the processor only has to wake once to set up the animation, then can go back to sleep while the controller chip itself loops the animations. This has a lot of battery saving potential.
Most of the juicy details on the microcode are in section 7.6.3 of the following document: [url]http://www.ti.com/lit/gpn/lp5523[/URL]
Remarks:
The kernel driver allows memory dumps of the controller chip which can allow for inspection of stock microcodes
Razer seems to load at least 2 unique microcodes. 1 for the "Spectrum" effect, and 1 for the "Static" and "Breathing" effects
The microcode can be overridden by the OS by writing to the LEDs sysfs directly, allowing for very complex effects (e.g. Music Visualization), but these require a wakelock or they pause when the screen goes off (not ideal).
The stock Chroma service may need to be disabled entirely to prevent conflicts with an OSS version (as it seems to load microcode at random times). Access to sysfs requires root for normal apps, so an OSS version would need root. System apps may have access to sysfs but I've not checked. There doesnt appear to be a native daemon controlling the logo but I may be wrong. An OSS version may want to apply microcodes for best effectiveness.
Since each pad can be controlled individually, you can actually set more than one colour at once, which looks pretty cool actually.
The LED sysfs paths are:
/sys/class/leds/lp5523:channel[0-8]/*
The device sysfs where microcode can be loaded can be accessed through a symlink in any channel, e.g.
/sys/class/leds/lp5523:channel0/device/*
Stock control methods:
The Chroma configurator app can build microcodes as evidenced by various string handling functions in the app decompiled code as well as a base "Blue Pulse" program which is exactly the length of a single memory page according to the kernel driver (but appears unused? Probably just issues with the decompile)
The microcode gets sent to a system framework service called "Ths", which seems to be what has access to and writes the sysfs values to communicate with the kernel. Dumpsys for the Ths service is blank, which is unusual for a stock android service so this is probably a custom service by Razer(why so lazy? ).
An OSS Chroma service could theoretically use the same system service, but this would require it to be installed as a system app and in GSIs (where that's practical), the service is not available anyway, so we would preferably not use it.
I kind of want to know what "THS" stands for...
I managed to decompile the framework of the stock ROM and can confirm the Ths service is a custom service which writes to sysfs directly, even referencing the LP5523 chip by name.
The THS service basically overwrites the memory on the controller directly with a fresh program each time an effect is applied. I was under the impression this is a bit risky, but whatevs. I might prefer using the kernel firmware interface. The service seems to take in three parameters each indicating the starting memory address for the program to run on each of the 3 programmable "engines". I think its possible for all 3 engines to run at once, but not sure. Programs 2 and 3 seem to get the same offset
The THS service never changes controller settings on its own, relying on the configurator app to receive broadcast intents to perform actions such as turning the controller off when the screen goes off (in medium battery mode). An OSS service can work in peace on the stock ROM by simply disabling the configurator app.
Amusingly Razer has used 1337 as a constant in some places in their code
Controller OEM support
Texas Instruments has software up on their website ([url]http://www.ti.com/lit/zip/snvc151[/URL]) which can compile an assembly style language called "Lysti" into a prebuilt memory image and set of program offsets ready to upload to the chip. (Relevant program is "LASM.EXE", runs fine on Wine)
They have a dev board available called TIDA-050013 and a demo video of the board on this page: [url]http://www.ti.com/product/LP5523/support[/URL]
I managed to figure out the demo program they have running in the video (its contained in the PDF tech doc for that product, but rather annoyingly with no line breaks ). It's posted in post #2 of this thread
Channel Mappings:
Channel 0: Left Green
Channel 1: Left Blue
Channel 2: Bottom Green
Channel 3: Bottom Blue
Channel 4: Right Green
Channel 5: Right Blue
Channel 6: Left Red
Channel 7: Bottom Red
Channel 8: Right Red
My OSS implementation can be found at https://github.com/CurtisMJ/LogoPlus and a compiled version is available in the Mods section of the Razer Phone 2 Forums
As a side note: Programs can continuously write to the sysfs values without having to close their file handle by flushing the stream after each write. This applies the value immediately. I used this in my OSS service to fade out the master fader.
Feel free to add any research

Texas Instruments TIDA-050013 Lysti demo program:
Code:
; This is a demo for the multicolor breathing.
; This demo to displays a slow ramp of
; all 3 colors for each tri-color LED
ENG1: dw 0000000100010001b
ENG2: dw 0000000010001100b
ENG3: dw 0000000001100010b
row1: dw 0000000001001001b ;Map B LED = D1,D4,D7 on the eval. board.
row2: dw 0000000010010010b ;Map G LED = D2,D5,D8 on the eval. board.
row3: dw 0000000100100100b ;Map R LED = D3,D6,D9 on the eval. board.
row4: dw 0000000011011011b ;Map B LED = D1,D2 on the eval. board.
row5: dw 0000000110110110b ;Map G LED = D2,D3 on the eval. board.
row6: dw 0000000101101101b ;Map R LED = D1,D3 on the eval. board.
row7: dw 0000000111111111b ;Map all LEDs on the eval. board.
.segment program1
mux_map_addr row7
set_pwm 0
loop1_0: mux_map_start row1 ;Map the first LED.
mux_ld_end row7 ;End address of the mapping data table.
loop1: ramp 2, 200 ;Increase PWM 0->PWM200 in 2 second.
ramp 2, -255 ;Decrease PWM 200->0% in 2 seconds.
wait 0.4 ;Wait for 0.4 seconds.
ramp 2, 200 ;Increase PWM 0->PWM200 in 2 second.
ramp 2, -255 ;Decrease PWM 200->0% in 2 seconds.
wait 0.4 ;Wait for 0.4 seconds.
mux_map_next ;Set the next row active in the mapping table.
branch 6,loop1 ;Loop 6 time
mux_map_addr row1
ramp 1.5, 200 ;Increase PWM 0->PWM200 in 1.5 second.
wait 0.4 ;Wait for 0.4 seconds.
wait 0.4 ;Wait for 0.4 seconds.
mux_map_addr row2
ramp 3, 200 ;Increase PWM 0->PWM200 in 3 second.
ramp 3, -255 ;Decrease PWM 200->0% in 3 seconds.
ramp 3, 200 ;Increase PWM 0->PWM200 in 3 second.
ramp 3, -255 ;Decrease PWM 200->0% in 3 seconds.
mux_map_addr row1
ramp 1.5, -255 ;Decrease PWM 100->0% in 1.5 seconds.
mux_clr
trigger s{2|3}
loop2: mux_map_addr ENG1
ramp 2, 255
ramp 2, -255
ramp 2, -255
branch 6, loop2
rst
.segment program2
trigger w{1}
loop3: mux_map_addr ENG2
ramp 2, -255
ramp 2, 255
ramp 2, -255
branch 6, loop3
rst
.segment program3
trigger w{1}
loop4: mux_map_addr ENG3
ramp 2, -255
ramp 2, -255
ramp 2, 255
branch 6, loop4
rst
Better mapping for Razer logo (top part of program)
Code:
; Slice L R B
; Cluster 1 2 3
; 876543210 | | |
ENG1: dw 0000000001011000b ; R G B
ENG2: dw 0000000010100001b ; G B R
ENG3: dw 0000000100000110b ; B R G
row1: dw 0000000000101010b ;Map B LED
row2: dw 0000000000010101b ;Map G LED
row3: dw 0000000111000000b ;Map R LED
row4: dw 0000000000111111b ;Map GB LED
row5: dw 0000000111010101b ;Map RG LED
row6: dw 0000000111101010b ;Map RB LED
row7: dw 0000000111111111b ;Map all LEDs on the eval. board.
With fixed mappings the demo program generates a sort of "Pinwheel" effect on the logo for it's last sequence which is pretty damn cool.
Attached is a very quick program I wrote (preproc.c) to process the .hex output from LASM.EXE into a shell script which will run the program if executed on the phone

Hey guys,
So I think I have it figured out and have been developing an app over the last couple evenings to replace the stock Chroma app.
I have a lot of time this afternoon and will attempt to get a working prototype which I'll post in the Mods section of the RP2 forums :victory:
EDITk building microcodes is bit shifting hell. May only have a workable prototype in a day or two sorry.

Don't care about a couple of days man, you're the only one doing this right now. Take a long as you need. And thanks for stepping up and doing this for everyone. Once we have the ability for more ROMs, this development is going to be a gamechanger. Thanks again.

Can not wait dude! Great job

Related

Priority256 in WM6.5 (i.e. Touch)

I noticed that some people have set their touch priority to relatively high values, I am not sure if this is the intent, but lower values actually raise the priority (although if you go too low, bad things can happen).
Here is some info:
>>>>
The priority system has 256 Priority Levels numbered 0 (zero) through 255. Priority level 0 is the highest priority level. The original eight priority levels for Windows CE 2.12 are mapped to levels 248 through 255.
Applications and device drivers should use the CeGetThreadPriority and CeSetThreadPriority APIs, instead of the legacy APIs, GetThreadPriority and SetThreadPriority. The legacy APIs are still available with the same interfaces as before, but those APIs have access to only the original eight priority levels.
The priority level system is divided into four ranges. The following table shows these ranges.
Levels Description
0 through 96
Reserved for real-time above drivers.
97 through 152
Used by the default Windows Mobile device drivers.
153 through 247
Reserved for real-time below drivers.
248 through 255
Mapped to non-real-time priorities.
The following table shows the default priority levels that are associated with device drivers. You can override these values by changing the source code for the drivers or by setting values in the registry. The registry paths in the table assume that the root Drivers key is HKEY_LOCAL_MACHINE\Drivers\BuiltIn; the registry uses hexadecimal values for the priority levels.
Decimal priority Hexadecimal priority Device driver Override
99
0x63
Power Manager resume thread
HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Power\ResumePriority256
100
0x64
USB Function
None
101, also uses +1 and -1 relative priorities
0x65, also uses +1 and -1 relative priorities
USB OHCD
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\OHCI\Priority256
101, also uses +1, +3, +5 and +7 relative priorities
0x65, also uses +1, +3, +5, and +7 relative priorities
USB UHCD
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\UHCI\Priority256
103
0x67
Serial
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial\Priority256
105, also uses +1 and +2 relative priorities
0x69, also uses +1 and +2 relative priorities
PCMCIA
HKEY_LOCAL_MACHINE\Drivers\PCMCIA\Priority256
109
0x6D
Touch
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Touch\Priority256
110, also uses +2 and +4 relative priorities
0x6E, also uses +2 and +4 relative priorities
IRSIR
HKEY_LOCAL_MACHINE\Comm\Irsir1\Parms\Priority256
116, also uses +2, +4, +6, +8, +10 and +12 relative priorities
0x74, also uses +2, +4, +6, +8, +10, and +12 relative priorities
NDIS
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\NDIS\Priority256
131
0x83
KITL
Override in the OEM Application Layer
. In OEMInit, set g_dwKITLThreadPriority (extern DWORD) to the desired priority before calling KitlInit.
131
0x83
VMINI
HKEY_LOCAL_MACHINE\Comm\VMini\Priority256
132
0x84
CxPort
HKEY_LOCAL_MACHINE\Comm\Cxport\Priority256
145
0x91
PS/2 Keyboard
HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\KEYBD\Priority256
148
0x94
IR Comm
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\IrComm\Priority256
150
0x96
TAPI (Unimodem)
HKEY_LOCAL_MACHINE\Drivers\Unimodem\Priority256
210
0xD2
WaveDev
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\WaveDev\Priority256
248
0xF8
PM (Power Manager)
HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Power\Priority256
249
0xF9
PS/2 Mouse
HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\MOUSE\Priority256
249
0xF9
Power Manager device registration thread
HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Power\PnPPriority256
249
0xF9
Power Manager system management thread
HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Power\SystemPriority256
249
0xF9
Power Manager activity timer thread
HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Power\TimerPriority256
250
0xFA
WaveAPI
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\WAPIMAN\Priority256
251
0xFB
Power Manager battery monitor thread
HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Power\PowerPollPriority256
Remarks
Threads in Normal (as apposed to Privileged) applications can use thread priorities 248 through 255.
Threads in Privileged applications can use any thread priority.

[MOD] Kernel - Display Backlight (WIP): 30 Limit now Removed! Down to 01

This project started becaues at night the Atrix display is far too bright. I've successfully compiled the kernel (faux's) and made some changes to the display driver, and from there I found a world of useful info and hacks which enhance our display.
Kernel Update
I have compiled faux's kernel and attached it to this thread. please note, this is NOT the cyanogen version of the kernel, only standard ROM's that use faux123's kernel. i can compile the cyan kernel next. this kernel change is simple, it defaults both the display and buttons to the lowest 5mA display mode. this way a reboot puts you right into the lowest mode, and you can manually set reg 17 to higher as-needed. reg 17 will stay set until the next next reboot.
NOTE: THIS RAMDISK WAS MINE PULLED FROM THE STOCK ROM "WITH EXTRAS", SO PLEASE IF YOU TRY A DIFFERENT ROM HAVE A NAND BACKUP READY TO RESTORE JUST IN CASE!!! I HAVENT TRIED THE OTHER ROMS.
it is the zImage and Ramdisk, so it is flashed like:
boot into fastboot (volume down and power on, then vol down till fastboot shows, then vol up to select).
Code:
moto-fastboot flash:raw boot zImage ramdisk.gz
sorry it's not a flashable zip. i purposely uses RAR so nobody tries to flash it with CWM.
Update - The brightness limit of 30 has now been removed:
The autobrightness can now go all the way down to 00 even with your stock kernel and ROM. The limit was coming from the frameworks. I've re-compiled the frameworks for the stock ROM and also for Cyan pre-beta 3. There are 2 frameworks attached to this post, stock and cyanogen. download from this post and unzip your correct file for your ROM, and ADB push the files to your phone:
Code:
- boot to recovery
- mount system
adb push framework-res.apk /system/framework/framework-res.apk
adb reboot
Update - Cyanogen Pre Beta 4 frameworks added
unzup and flash with adb shown above.
Here is what is found in the frameworks, under res/values/arrays.xml:
Code:
10
50
100
150
200
700
1300
2000
3000
4000
5000
6000
7000
8000
9000
20
20
34
46
62
81
100
119
137
138
153
170
187
206
221
255
255
255
255
192
128
0
0
0
0
0
0
0
0
0
0
0
I changed the first value in config_autoBrightnessLcdBacklightValues from a 20 to a 2, and now in auto brightness mode the screen goes all the way down to 2.
Update:
We now have the proper official data sheet (link below) thanks to Saltinbas.
Documentation - Data Sheet
Our backlight chip is the lm3532, which is basically same as lm3530 which is used in the moto droid. i've read the entire data sheet twice and still trying to grasp everything. the data sheet can be found here:
http://www.national.com/ds/LM/LM3532.pdf
Not all registers are exactly the same, so some reverse engineering is needed.
Source Code (Kernel)
The relevant kernel source code:
leds-lm3532.c - Driver
leds-lm3532.h - Headers
board-mot-lights.c - Initialization
What I've Tried So Far
The first change I made was in board-mot-lights.c.
Code:
struct lm3532_platform_data lm3532_pdata = {
.flags = LM3532_CONFIG_BUTTON_BL | LM3532_HAS_WEBTOP,
.init = disp_backlight_init,
.power_on = disp_backlight_power_on,
.power_off = disp_backlight_power_off,
.ramp_time = 0, /* Ramp time in milliseconds */
.ctrl_a_fs_current = LM3532_26p6mA_FS_CURRENT,
.ctrl_b_fs_current = LM3532_8p2mA_FS_CURRENT,
.ctrl_a_mapping_mode = LM3532_LINEAR_MAPPING,
.ctrl_b_mapping_mode = LM3532_LINEAR_MAPPING,
.ctrl_a_pwm = 0x82,
};
I changed lines 99 and 100 to this:
Code:
.ctrl_a_fs_current = LM3532_5mA_FS_CURRENT,
.ctrl_b_fs_current = LM3532_5mA_FS_CURRENT,
Success
And bingo, display brightness reduced significantly lower than stock. the display has many different "modes" and I went right to the lowest on the list. Here are the brightness modes which can be found in the header file leds-lm3532.h:
Brightness Config Values (Header File)
Code:
#define LM3532_5mA_FS_CURRENT 0x00
#define LM3532_5p8mA_FS_CURRENT 0x01
#define LM3532_6p6mA_FS_CURRENT 0x02
#define LM3532_7p4mA_FS_CURRENT 0x03
#define LM3532_8p2mA_FS_CURRENT 0x04
#define LM3532_9mA_FS_CURRENT 0x05
#define LM3532_9p8mA_FS_CURRENT 0x06
#define LM3532_10p6mA_FS_CURRENT 0x07
#define LM3532_11p4mA_FS_CURRENT 0x08
#define LM3532_12p2mA_FS_CURRENT 0x09
#define LM3532_13mA_FS_CURRENT 0x0A
#define LM3532_13p8mA_FS_CURRENT 0x0B
#define LM3532_14p6mA_FS_CURRENT 0x0C
#define LM3532_15p4mA_FS_CURRENT 0x0D
#define LM3532_16p2mA_FS_CURRENT 0x0E
#define LM3532_17mA_FS_CURRENT 0x0F
#define LM3532_17p8mA_FS_CURRENT 0x10
#define LM3532_18p6mA_FS_CURRENT 0x11
#define LM3532_19p4mA_FS_CURRENT 0x12
#define LM3532_20p2mA_FS_CURRENT 0x13
#define LM3532_21mA_FS_CURRENT 0x14
#define LM3532_21p8mA_FS_CURRENT 0x15
#define LM3532_22p6mA_FS_CURRENT 0x16
#define LM3532_23p4mA_FS_CURRENT 0x17
#define LM3532_24p2mA_FS_CURRENT 0x18
#define LM3532_25mA_FS_CURRENT 0x19
#define LM3532_25p8mA_FS_CURRENT 0x1A
#define LM3532_26p6mA_FS_CURRENT 0x1B
#define LM3532_27p4mA_FS_CURRENT 0x1C
#define LM3532_28p2mA_FS_CURRENT 0x1D
#define LM3532_29mA_FS_CURRENT 0x1E
#define LM3532_29p8mA_FS_CURRENT 0x1F
Then i discovered that we don't even need to compile a new kernel to access this chip. We have the proper sysfs files already given to us by motorola engineers. here are some useful commands:
Terminal Commands
Use terminal app and navigate to:
Code:
su
cd sys/bus/i2c/drivers/lm3532/0-0038/leds/lcd-backlight
you can set any of the above modes you want. as an example let's say I want to set to maximum brightness mode, use the corresponding hex value in the header file from earlier, and type:
Code:
echo 17 1F > registers
that sets register 0x17 (the brightness register) with value 0x1F (the maximum brightness value from the list).
To set the minimum brightness:
Code:
echo 17 00 > registers
now for those of you who would like to help out with this and test other registers, you can see all register values by typing:
Code:
cat registers
that brings up this:
Code:
OUTPUT_CFG_REG (0x10) = 0xD4
START_UP_RAMP_REG (0x11) = 0xC0
RUN_TIME_RAMP_REG (0x12) = 0xC0
CTRL_A_PWM_REG (0x13) = 0x86
CTRL_B_PWM_REG (0x14) = 0x82
CTRL_C_PWM_REG (0x15) = 0x82
CTRL_A_BR_CFG_REG (0x16) = 0xE3
CTRL_A_FS_CURR_REG (0x17) = 0xFF
CTRL_B_BR_CFG_REG (0x18) = 0xE3
CTRL_B_FS_CURR_REG (0x19) = 0xE4
CTRL_C_BR_CFG_REG (0x1a) = 0xF1
CTRL_C_FS_CURR_REG (0x1b) = 0xF3
ENABLE_REG (0x1d) = 0xFF
FEEDBACK_ENABLE_REG (0x1c) = 0xF9
ALS1_RES_SEL_REG (0x20) = 0xE0
ALS2_RES_SEL_REG (0x21) = 0xE0
ALS_CFG_REG (0x23) = 0x44
ALS_ZONE_REG (0x24) = 0xF0
ALS_BR_ZONE_REG (0x25) = 0xF8
ALS_UP_ZONE_REG (0x26) = 0xF8
ZB1_REG (0x60) = 0x35
ZB2_REG (0x61) = 0x33
ZB3_REG (0x62) = 0x6A
ZB4_REG (0x63) = 0x66
CTRL_A_ZT1_REG (0x70) = 0x51
CTRL_A_ZT2_REG (0x71) = 0x66
CTRL_A_ZT3_REG (0x72) = 0x99
CTRL_A_ZT4_REG (0x73) = 0xCC
CTRL_A_ZT5_REG (0x74) = 0xFF
CTRL_B_ZT1_REG (0x75) = 0x00
CTRL_B_ZT2_REG (0x76) = 0x66
CTRL_B_ZT3_REG (0x77) = 0x99
CTRL_B_ZT4_REG (0x78) = 0xCC
CTRL_B_ZT5_REG (0x79) = 0xFF
CTRL_C_ZT1_REG (0x7a) = 0x33
CTRL_C_ZT2_REG (0x7b) = 0x66
CTRL_C_ZT3_REG (0x7c) = 0x99
CTRL_C_ZT4_REG (0x7d) = 0xCC
CTRL_C_ZT5_REG (0x7e) = 0xFF
VERSION_REG (0xcc) = 0xE4
You can set any register XX with any value YY as follows:
Code:
echo XX YY > registers
additional knowledge i've learned so far. Ctrl A is the main display. Ctrl B is the bottom buttons. Ctrl C is webtop. So all we really care about are Ctrl A registers for now.
Additional Info
The display is set to linear mapping mode by default. but changing to exponential mapping mode gives a huge range from minimum to maximum brightness. but it's still not ready for primetime. to try out exponential, type:
Code:
echo 16 01 > registers
now go to your main phone settings, display, brightness, and drag the slider from min to max and see the enormous full range now available. dont worry, to reset exponential mode just lock the screen with power button then unlock, exponential mode gets cleared. that can be fixed later in the kernel when we get it working better.
just setting to minimum brightness alone gives a huge increase in battery life for display-on time, specifically at night. there's more potential to get out of this chip so hopefully you guys can dig up more stuff that i'm missing.
at some point I can compile the kernel with any changes discovered from this thread, and perhaps we can merge the code changes back into the kernel repo if faux doesn't mind.
Problem 1
I don't fully understand the meaning of the header file brightness values. The names list current mA values, that is clear. but there are also other info in the name which I don't understand yet.
similarly, in the data sheet, they give detailed examples of how to calculate the current draw of each brightness mode, and walk thru setting up the general configuration register. i've been reverse engineering the registers by looking at the data sheet, seeing each 8 bits and what they are assigned, then using appropriate hex value to turn off and on each of those bits in the output config reg. i echo a value, and see the result. most of the time it matches the data sheet, but not always.
Problem 2
There are also 4 boundary zones which trigger the backlight to adjust it's brightness. i've attempted to set these boundaries to different values, but so far i've not had any success with this.
Problem 3
Before this all started, no matter what the display brightness only goes down to 30 from a range of 0-255. even changing all the modes i've listed above, in every one it stops at 30. you can check brightness level by:
Code:
cat brightness
I'm stumped on where the 30 limit is coming from.
Ultimately, we can permanently change the following code in board-mot-lights.c to whatever desired values we want to be in the kernel permanently:
Code:
struct lm3532_platform_data lm3532_pdata = {
.flags = LM3532_CONFIG_BUTTON_BL | LM3532_HAS_WEBTOP,
.init = disp_backlight_init,
.power_on = disp_backlight_power_on,
.power_off = disp_backlight_power_off,
.ramp_time = 0, /* Ramp time in milliseconds */
.ctrl_a_fs_current = LM3532_26p6mA_FS_CURRENT,
.ctrl_b_fs_current = LM3532_8p2mA_FS_CURRENT,
.ctrl_a_mapping_mode = LM3532_LINEAR_MAPPING,
.ctrl_b_mapping_mode = LM3532_LINEAR_MAPPING,
.ctrl_a_pwm = 0x82,
};
And a companion app could also be made to automate the setting of these registers and such.
last thing, above notice the PWM value being set to 0x82. this is pulse width modulation mode, and is a significant power saving method in electronics. fortunately this is turned on by default, which is what the value 0x82 is doing. i've experimented turning it off and on for the hell of it.
hope some experts can join in this thread and see how far it goes. any questions feel free to ask.

Curious about the difference between software modification (screen brightness apps) and kernel modification (for brightness)

Excellent I like tinkerers and thanks for info so far

Magnetox said:
Curious about the difference between software modification (screen brightness apps) and kernel modification (for brightness)
Click to expand...
Click to collapse
Well this project is both kernel and could use an app to control the registers. But primarily this is to make kernel changes for now.

is this able to lower the brightness to BELOW the '2' setting? that's as low as AdjBrightness app lets me go, and also doesn't allow me to dim the home buttons. it would be nice to be able to dim the buttons at least, especially if watching a movie or something in the dark.

dLo GSR said:
is this able to lower the brightness to BELOW the '2' setting? that's as low as AdjBrightness app lets me go, and also doesn't allow me to dim the home buttons. it would be nice to be able to dim the buttons at least, especially if watching a movie or something in the dark.
Click to expand...
Click to collapse
Yes this can absolutely dim the buttons, anywhere from off to full brightness. Just echo to ctrl B register.
I'm not aware of the display app you mentioned. Does it do all the things I already listed in this thread? If so I feel dumb, I've not heard of the app you said.
Edit: I see that app in the market. This thread is specific to the atrix kernel, so it offers much more control. Activate exponential mapping mode and the display brightness goes down so low you wont even believe it. We'd then maybe make an app to automate it.

Forgive my ignorance, but the app SuperDim changes the brightness on my Atrix. Perhaps you guys are talking about something else though?
The lowest brightness setting is still much too bright to enjoy my Atrix in the dark (lol). The wife gets pissed... but this app definitely works.

Very cool!
'cat registers' only works when display is on. I'll have to see if an app can be done that doesn't have to fight the system.
Cheers!

or you could get an app called screen filter which does all this o.o

xepter said:
or you could get an app called screen filter which does all this o.o
Click to expand...
Click to collapse
Well, no, actually.

Hopefully something similiar to this, kernel maybe, all contains settings for the touch screen(digitizer)and we can alleviate the pesky rain drop detection issue.
A little late for me to start playing with this, maybe tomorrow!
Thanks
Sent from my MB860 using xda premium

what this is doing is reducing the current sent to the backlight to dim it.
Screen filter doesnt reduce current to the backlight past the stock minimum limit. It just puts a transparent "mask" over the display with the opacity depending on your setting, done entirely in software.

m0biusace said:
what this is doing is reducing the current sent to the backlight to dim it.
Screen filter doesnt reduce current to the backlight past the stock minimum limit. It just puts a transparent "mask" over the display with the opacity depending on your setting, done entirely in software.
Click to expand...
Click to collapse
Yes you bring up my next point, this isn't just brightness. This let's us reduce the current draw pulled by the display, and a good amount at that if you read the data sheet and look at the registers.
Additionally this let's us set and change the zone boundaries of the light sensor. It let's us change mapping mode between linear and exponential.
It also let's us control PWM, though that should just stay on all the time. Also there is ramp time register, which is set to zero by Motorola, so that might be useful.
Also there is the brightness config reg, full scale current reg, and general output config reg. All these look to have purpose needed to be tested.
There are many registers to tweak which gives us control, and that's the goal of this thread I think. Once we crack it all open then we can make permanent kernel changes if we want. Or an app would work. I think we could do something crazy like double screen time by finding optimal combo of reg settings, e.g. set min brightness mode with exponential mapping mode, then adjust the zone boundaries slightly,and it literally could give huge display savings for power. At least worth testing to see.

faux123 said:
Excellent I like tinkerers and thanks for info so far
Click to expand...
Click to collapse
Dude thank you for letting me compile your kernel. Much appreciated! And tinkering is what's fun about android!

some interesting behavior here:
lowest brightness in Stock 2.3.4 is "20", you can adjust to "2" by using app "adjbrightness", while you can set brightness lower to "1" in "moboplayer".
Even though, the "1" brightness is not good enough.
I'm wondering if this MOD can make brightness lower than "1"?

NFHimself said:
Very cool!
'cat registers' only works when display is on. I'll have to see if an app can be done that doesn't have to fight the system.
Cheers!
Click to expand...
Click to collapse
Yeah the driver is overriding some things, we could easily fix the code though. For example if you change the gen config reg to activate a different mode, soon as screen goes off locked the register is set back to previous value cause its hard coded. We just change that. So during testing I just keep the screen on.
I do have a battery app which does the echo and cat commands already written. Could just change the path and use it for this project...

kenyloveg said:
some interesting behavior here:
lowest brightness in Stock 2.3.4 is "20", you can adjust to "2" by using app "adjbrightness", while you can set brightness lower to "1" in "moboplayer".
Even though, the "1" brightness is not good enough.
I'm wondering if this MOD can make brightness lower than "1"?
Click to expand...
Click to collapse
Yes. Just enable exponential mapping mode, then use the slider in main display setting to see the full range.
echo 16 01 > registers
Be ready, super dim with that setting. Note still even with that being much lower brightness, the actual brightness value still wont go lower than 30. I can't figure out why.

SuperDim
As member bongd mentions already, SuperDim does the thing, free on the Market. I've pressed thanks button to show appreciation to the OP's efforts.

maajstor said:
As member bongd mentions already, SuperDim does the thing, free on the Market. I've pressed thanks button to show appreciation to the OP's efforts.
Click to expand...
Click to collapse
Superdim does not allow the brightness to even get close to the minimum level that the screen does by setting the registers. Testing is needed and that's kinda the point here.
So the lm3532 chip has brightness capabilities from 5mA up to 29the mA. Stock value in the kernel is set to very high at 26 mA. So just setting the lowest brings the current draw to 5 mA. The data sheet then shows the equation gives final result of close to 0.78 mA with all set properly. So there's savings to be had which is what needs to be tested here.
As an example, last night I changed to the lowest register setting, and after an hour of web screen-on time I was still at 86%the battery still.

maajstor said:
As member bongd mentions already, SuperDim does the thing, free on the Market. I've pressed thanks button to show appreciation to the OP's efforts.
Click to expand...
Click to collapse
Wow! You guys just aren't getting it. The apps you find in the market do not do the same thing. "Yes in the aspect they dim the screen" but they do it in to completely different ways. The way the op is talking about could add hours of battery life to are phones if done right. Because it changes how much power the display uses. There is not an app in the market or out that does that.

[R&D][MOD]Nexus S Color Correction

This started out as an idea I had while trying to calibrate the screen color of my Nexus S using a colorimeter. While a lot of users are not particularly picky about colors, I do hope quite a number of people would also be interested in this. To give a clearer understanding for all, I'll put in a not-so-short introduction.
As most of us would know, AMOLED screens, while good in terms of brightness and contrast, tend to distort colors. If you're viewing an image on an AMOLED screen, you'll likely notice areas which appear oversaturated and have blown-out details. The reason behind this is that our AMOLED screens have a much wider gamut (i.e. displays more colors) than how images are encoded. If you look at the image below, the bigger triangle represents the set of colors that the AMOLED screen can display. The smaller triangle is the sRGB reference color which is how Android and most images are encoded.

Unfortunately for us, the Android OS isn't aware of this difference. A color with value of #00FF00 (pure green) should look like the green at the upper peak of the smaller triangle. But in reality, it is shown to us as the green of the larger triangle. This remapping between the two color spaces causes lighter shades of color to appear darker (or actually more saturated).
So far, the solution to fixing the problem is through the use of voodoo color (cheers to supercurio). Voodoo allows for the modification of gamma which somehow compensates for the saturation levels of the colors. Also, color multipliers allow for the shifting of the white point. White point, you ask? See, the intersection of the dotted lines? That is the white point which is how white would appear on the screen. Some like warm colors (white points to the right) while cool colors are to the left. However, gamma and multipliers only operate on a single color at a time. This means that the larger triangle will always remain the same shape regardless of the settings we use. Colors would look better but still not the same as the original intent.
So what can we do about it? Well one way would be by analyzing the way in which colors are mapped to a visually-oriented reference (such as the xyY/XYZ space shown in the above image). A standard sRGB image would be mapped using:

While the Nexus S (using the marmite kernel by bedalus with equal multipliers) would map out like:

In effect, you can find a map to convert the intended sRGB colors to the values usable by the screen to simulate the original rendering intent of the colors. This is done by using the following relationship:

Note that the other non-labelled matrix here is simply a way to shift the white point from 6500K (warm) to 9300K (cool) to display good colors on our devices using chromatic adaptation. The end effect is a means to fix color by simply mixing together red, green, and blue values (after gamma correction to be strictly accurate but this has its tolerances). The mix is just as shown above or in a more non-scientific notation:
Code:
R = 0.7043 * R + 0.3440 * B - 0.0028 * B
G = 0.0160 * R + 0.8930 * G + 0.0598 * B
B = 0.0195 * R + 0.0846 * G + 1.1185 * B
As an example, I've uploaded a before-and-after comparison of a test image. On a computer display, the right image (modified) would appear weird compared to the left image but if you load it up (or just view it) on your phone, you can see that the right one actually looks better (no oversaturation). This would be better if you have voodoo color with the multipliers set to more or less equal values.

The task then is to implement this on a kernel level (or similar) which I will touch on my next post (maybe tomorrow). Note that I have not successfully done the modifications as I lack the development skillz to match. In this regard, I would like to solicit the assitance of the dev community with a much wider experience with these things than I do.

So I decided to continue writing this today...
Unlike the voodoo color codes which rely on hardware (TL2796 AMOLED driver) to implement gamma correction, the color mixing process is a bit more involved on the software end. There are no chips on the Nexus S which can be configured to perform the mixing process natively. Instead, I have a few ideas on the implementation of the mixing process.
1. Rewrite the framebuffer
I've attempted doing this using native code by opening the /dev/graphics/fb0 device but the problem lies in timing. If the timing is off, the mixing either never occurs or is repeated several times for a given frame causing color distortions. This is further complicated by the use of double buffering on the device. Even more so with the switching behavior between double and triple buffering in JB! I've tried hijacking the VSYNC signal to operate on the timing (see colormix.c attached) but the result is still very glitchy. Or I may be doing it wrong...
2. Handle all routines that write to the framebuffer
Another way would be to handle all the writes to the framebuffer device. This eliminates the need for timing as processing occurs only once as the data is transferred to the framebuffer. I've seen the codes for cfbcopyarea.c, cfbimgblit.c, and cfbfillrect.c but I'm not sure where direct writes to the framebuffer (using mmap access) are handled (if at all handled). So again, I'm not too sure about this one.
3. Hijack the interface from the LCD driver
Yet another unsure idea by the way. Since the LCD driver interact with the physical hardware through 24 GPIO pins, there should be some code describing how data is transferred to these pins. At that level, it might be possible to manipulate the signal just before it is sent to avoid timing issues mentioned earlier.
Most of these ideas are speculative from a person who is not really that deep into development (I'm more of an image processing researcher ). Any feedback and ideas from the community would be great!

I'm down with matrices. Sign me up!

some good ideas here, if you manage to calibrate our screens without using voodoo, this idea can potentially be used on other amoled devices such as s3 to calibrate it, removing it's over-saturation

bedalus said:
I'm down with matrices. Sign me up!
Click to expand...
Click to collapse
LOL. Matrices are fun! Thanks bedalus!
By the way, I took a look at the driver codes and it may be possible to find the next framebuffer using ioctl (from an external program).
Code:
case S3CFB_GET_CURR_FB_INFO:
next_fb_info.phy_start_addr = fix->smem_start;
next_fb_info.xres = var->xres;
next_fb_info.yres = var->yres;
next_fb_info.xres_virtual = var->xres_virtual;
next_fb_info.yres_virtual = var->yres_virtual;
next_fb_info.xoffset = var->xoffset;
next_fb_info.yoffset = var->yoffset;
next_fb_info.lcd_offset_x = 0;
next_fb_info.lcd_offset_y = 0;
if (copy_to_user((void *)arg,
(struct s3cfb_next_info *) &next_fb_info,
sizeof(struct s3cfb_next_info)))
return -EFAULT;
break;
Invoking this should at least resolve the double buffering issues if timed correctly with VSYNC. Again, IF.
noobiekins said:
some good ideas here, if you manage to calibrate our screens without using voodoo, this idea can potentially be used on other amoled devices such as s3 to calibrate it, removing it's over-saturation
Click to expand...
Click to collapse
Yes actually. You just need colorimeter readings of the locations of the red, green, and blue primaries to build the matrix for any other device and compensate for it.

So based on my last post I tried looking at the behavior of the framebuffer device. It seems that there are a few parameters which are being used by the device namely:
xres/yres - dimensions of the visible image in pixels
xres_virtual/yres_virtual - dimensions of the virtual image in pixels
xoffset/yoffset - position in the framebuffer being used
Click to expand...
Click to collapse
Dumping from a test program, I get one of two sets of values from the framebuffer device:
Code:
Start address: 4debf000
Visible resolution: 480, 800
Virtual resolution: 480, 5600
Offsets: 0, 800
Start address: 4debf000
Visible resolution: 480, 800
Virtual resolution: 480, 5600
Offsets: 0, 0
This more or less tells us that the framebuffer memory is actually divided into multiple buffers each with the visible size (480x800) of the display. They alternate (using the offsets) to provide the double buffering effect Android uses. However, what I can't understand is why there are 7 buffers allocated for the device instead of at most 3 (for triple buffering). It might be useful to take snapshots of the entire framebuffer and write them to consecutive bitmaps but I won't bother with that at the moment.
I've also tried using this behavior to synchronize the framebuffer writes using changes in the offset as a trigger:
Code:
for (;;)
{
do
{
// Extract variable framebuffer information
if(ioctl(fd, FBIOGET_VSCREENINFO, &next_vi) < 0)
{
perror("Cannot extract variable framebuffer information");
return -1;
}
} while (next_vi.yoffset == cur_vi.yoffset);
...
<insert color mixing here>
...
}
Unfortunately, the screen still doesn't update as desired. Lots of flickering involved. I'm not sure if the memory accesses are just too slow such that the screen refreshes before we completely rewrite the framebuffer or if its some other problem. I've attached the full code for anyone who might be able to shed some light on this. In this code, I just did a dummy rewrite (red = green, blue = green) instead of color mixing to avoid computation therefore minimizing CPU loading and to have a more pronounced effect on the screen.

I'm clueless about video, but I'm digging around... These are the files that compile in /drivers/video/
Code:
/home/dave/android/androidkernel/drivers/video/backlight/lcd.o
/home/dave/android/androidkernel/drivers/video/backlight/backlight.o
/home/dave/android/androidkernel/drivers/video/backlight/built-in.o
/home/dave/android/androidkernel/drivers/video/fb_notify.o
/home/dave/android/androidkernel/drivers/video/display/built-in.o
/home/dave/android/androidkernel/drivers/video/fb.o
/home/dave/android/androidkernel/drivers/video/fbsysfs.o
/home/dave/android/androidkernel/drivers/video/samsung/s3cfb.o
/home/dave/android/androidkernel/drivers/video/samsung/s3cfb_nt35580.o
/home/dave/android/androidkernel/drivers/video/samsung/s3cfb_tl2796.o
/home/dave/android/androidkernel/drivers/video/samsung/s3cfb_fimd6x.o
/home/dave/android/androidkernel/drivers/video/samsung/built-in.o
/home/dave/android/androidkernel/drivers/video/cfbimgblt.o
/home/dave/android/androidkernel/drivers/video/fbmem.o
/home/dave/android/androidkernel/drivers/video/modedb.o
/home/dave/android/androidkernel/drivers/video/cfbcopyarea.o
/home/dave/android/androidkernel/drivers/video/fbcmap.o
/home/dave/android/androidkernel/drivers/video/omap2/displays/built-in.o
/home/dave/android/androidkernel/drivers/video/omap2/built-in.o
/home/dave/android/androidkernel/drivers/video/built-in.o
/home/dave/android/androidkernel/drivers/video/fbcvt.o
/home/dave/android/androidkernel/drivers/video/cfbfillrect.o
/home/dave/android/androidkernel/drivers/video/fbmon.o
I'm combing through these files now to see if there's any obvious points to hack in.

bedalus said:
I'm clueless about video, but I'm digging around... These are the files that compile in /drivers/video/
Code:
/home/dave/android/androidkernel/drivers/video/backlight/lcd.o
/home/dave/android/androidkernel/drivers/video/backlight/backlight.o
/home/dave/android/androidkernel/drivers/video/backlight/built-in.o
/home/dave/android/androidkernel/drivers/video/fb_notify.o
/home/dave/android/androidkernel/drivers/video/display/built-in.o
/home/dave/android/androidkernel/drivers/video/fb.o
/home/dave/android/androidkernel/drivers/video/fbsysfs.o
/home/dave/android/androidkernel/drivers/video/samsung/s3cfb.o
/home/dave/android/androidkernel/drivers/video/samsung/s3cfb_nt35580.o
/home/dave/android/androidkernel/drivers/video/samsung/s3cfb_tl2796.o
/home/dave/android/androidkernel/drivers/video/samsung/s3cfb_fimd6x.o
/home/dave/android/androidkernel/drivers/video/samsung/built-in.o
/home/dave/android/androidkernel/drivers/video/cfbimgblt.o
/home/dave/android/androidkernel/drivers/video/fbmem.o
/home/dave/android/androidkernel/drivers/video/modedb.o
/home/dave/android/androidkernel/drivers/video/cfbcopyarea.o
/home/dave/android/androidkernel/drivers/video/fbcmap.o
/home/dave/android/androidkernel/drivers/video/omap2/displays/built-in.o
/home/dave/android/androidkernel/drivers/video/omap2/built-in.o
/home/dave/android/androidkernel/drivers/video/built-in.o
/home/dave/android/androidkernel/drivers/video/fbcvt.o
/home/dave/android/androidkernel/drivers/video/cfbfillrect.o
/home/dave/android/androidkernel/drivers/video/fbmon.o
I'm combing through these files now to see if there's any obvious points to hack in.
Click to expand...
Click to collapse
Great! And here I was having trouble figuring out which files were actually being used...
I'm not sure about other types of hacks but if we're talking about framebuffer rewriting (like what I've been trying to do), the following segment in s3cfb.c may be useful:
Code:
static irqreturn_t s3cfb_irq_frame(int irq, void *data)
{
struct s3cfb_global *fbdev = (struct s3cfb_global *)data;
s3cfb_clear_interrupt(fbdev);
fbdev->vsync_timestamp = ktime_get();
wmb();
wake_up_interruptible(&fbdev->vsync_wq);
return IRQ_HANDLED;
}
Assuming the system interrupt for VSYNC is enabled (which I assume to be the case otherwise the Choreographer API of JB shouldn't work), then maybe a hack there could be done to process the framebuffer just in time with the frame refresh. This is of course under the assumption that the rewrite is fast enough. I'll try sorting through those files as well to see if there's some easier hack.

Couldn't you pre-process the data before it gets to the fb? It sounds like you want to read it and rewrite it. Did i understand correctly?

bedalus said:
Couldn't you pre-process the data before it gets to the fb? It sounds like you want to read it and rewrite it. Did i understand correctly?
Click to expand...
Click to collapse
Yep, you got it right. Right now, I'm trying to read and re-write but as you said, ideally it should be pre-processed before it even arrives at the framebuffer. I'm not sure if its possible though. Applications can access the framebuffer by mmap-ing it onto shared memory which they can write directly to. I've found functions for fb_write and fb_mmap (both in fbmem.c) but I'm not sure if they're being used internally by the kernel to handle mmap and write requests. I have too little knowledge of kernel processes to know for sure.

fb_write looks fully internal to me.
It looks like the OS is given access in drivers/video/fbsysfs.c

bedalus said:
fb_write looks fully internal to me.
It looks like the OS is given access in drivers/video/fbsysfs.c
Click to expand...
Click to collapse
I'm not quite sure what you mean by internal. Does that mean that if we modify it, we can change how all data is written to the framebuffer?
As for fbsysfs.c, I can see how the OS writes the variable information pertaining to the framebuffer. However, I can't seem to find any reference to the actual data being written to the framebuffer. Did I miss something?

nightsky87 said:
I'm not quite sure what you mean by internal. Does that mean that if we modify it, we can change how all data is written to the framebuffer?
As for fbsysfs.c, I can see how the OS writes the variable information pertaining to the framebuffer. However, I can't seem to find any reference to the actual data being written to the framebuffer. Did I miss something?
Click to expand...
Click to collapse
I'm not 100% sure yet, but I think if you needed to, there is probably a way to hack in at that point.
However supercurio hacked into the gamma here arch/arm/mach-s5pv210/herring-panel.c
...and RGB: drivers/video/samsung/s3cfb_tl2796.c
Is your gamut correction totally independent of RGB/gamma?
EDIT: Oh, I see it now. You have to correct R based partly on G and B etc. Okay. I'll keep looking.

bedalus said:
I'm not 100% sure yet, but I think if you needed to, there is probably a way to hack in at that point.
However supercurio hacked into the gamma here arch/arm/mach-s5pv210/herring-panel.c
...and RGB: drivers/video/samsung/s3cfb_tl2796.c
Is your gamut correction totally independent of RGB/gamma?
EDIT: Oh, I see it now. You have to correct R based partly on G and B etc. Okay. I'll keep looking.
Click to expand...
Click to collapse
Yep... I realized that my attempt at buffer rewrites read and write from the framebuffer one byte at a time! Major I/O overheads! I totally forgot about that.
I'll try rewriting that code as well.

Here's another file:
Code:
include/linux/tl2796.h
It contains the template for the RGB multipliers.
EDIT: I'm trying to see which files use this header now
EDIT: arch/arm/mach-s5pv210/herring-panel.c
...and drivers/video/samsung/s3cfb_tl2796.c
...these are the only two files, so the matrix transformation you want to perform probably needs to happen in one of these files only.

bedalus said:
Here's another file:
Code:
include/linux/tl2796.h
It contains the template for the RGB multipliers.
EDIT: I'm trying to see which files use this header now
EDIT: arch/arm/mach-s5pv210/herring-panel.c
...and drivers/video/samsung/s3cfb_tl2796.c
...these are the only two files, so the matrix transformation you want to perform probably needs to happen in one of these files only.
Click to expand...
Click to collapse
I think the RGB multipliers you're referring to are the same ones used by supercurio and they operate on a per-color basis. In fact, those two files don't directly modify RGB values as far as I can tell. By the time the signal reaches the TL2796 AMOLED driver, they're already mapped to the GPIO_LCD_D<> ports (see /arch/arm/mach-s5pv210/include/mach/gpio-herring.h for the physical mapping).
EDIT:
I did a grep on fb_write and bumped into this code in /include/linux/fb.h:
Code:
/* For framebuffers with strange non linear layouts or that do not
* work with normal memory mapped access
*/
ssize_t (*fb_read)(struct fb_info *info, char __user *buf,
size_t count, loff_t *ppos);
ssize_t (*fb_write)(struct fb_info *info, const char __user *buf,
size_t count, loff_t *ppos);
Since I can confirm that the framebuffers with our devices can support mmap, I suppose this means any app can directly read/write to the framebuffer without going through some intermediate function. This leaves us with framebuffer rewrites or hijacking the transfer of data from framebuffer to physical device. I like the second option better.

nightsky87 said:
I think the RGB multipliers you're referring to are the same ones used by supercurio and they operate on a per-color basis. In fact, those two files don't directly modify RGB values as far as I can tell. By the time the signal reaches the TL2796 AMOLED driver, they're already mapped to the GPIO_LCD_D<> ports (see /arch/arm/mach-s5pv210/include/mach/gpio-herring.h for the physical mapping).
Click to expand...
Click to collapse
After a lot of head scratching, I see what you mean.
I performed a search for S5PV210_GPF* and found these files:
Code:
drivers/gpio/gpio-s5pv210.c
arch/arm/mach-s5pv210/herring-panel.c
arch/arm/mach-s5pv210/setup-fb.c
arch/arm/mach-s5pv210/mach-herring.c
...all of which are compiled into the kernel.
Probably if the best place to intervene is on the GPIOs, it must be in one of these files. I'll keep looking!
EDIT: I just saw your edit in the previous post, and I agree! Option 2 seems preferable.

bedalus said:
After a lot of head scratching, I see what you mean.
I performed a search for S5PV210_GPF* and found these files:
Code:
drivers/gpio/gpio-s5pv210.c
arch/arm/mach-s5pv210/herring-panel.c
arch/arm/mach-s5pv210/setup-fb.c
arch/arm/mach-s5pv210/mach-herring.c
...all of which are compiled into the kernel.
Probably if the best place to intervene is on the GPIOs, it must be in one of these files. I'll keep looking!
EDIT: I just saw your edit in the previous post, and I agree! Option 2 seems preferable.
Click to expand...
Click to collapse
Ironically, register definitions don't seem to be in those files. They probably used a different set of defines. What I did find was this in /drivers/video/samsung/s3cfb_fimd6x.c:
Code:
int s3cfb_set_buffer_address(struct s3cfb_global *ctrl, int id)
{
struct fb_fix_screeninfo *fix = &ctrl->fb[id]->fix;
struct fb_var_screeninfo *var = &ctrl->fb[id]->var;
struct s3c_platform_fb *pdata = to_fb_plat(ctrl->dev);
dma_addr_t start_addr = 0, end_addr = 0;
u32 shw;
if (fix->smem_start) {
start_addr = fix->smem_start + (var->xres_virtual *
(var->bits_per_pixel / 8) * var->yoffset);
end_addr = start_addr + fix->line_length * var->yres;
}
if (pdata->hw_ver == 0x62) {
shw = readl(ctrl->regs + S3C_WINSHMAP);
shw |= S3C_WINSHMAP_PROTECT(id);
writel(shw, ctrl->regs + S3C_WINSHMAP);
}
writel(start_addr, ctrl->regs + S3C_VIDADDR_START0(id));
writel(end_addr, ctrl->regs + S3C_VIDADDR_END0(id));
if (pdata->hw_ver == 0x62) {
shw = readl(ctrl->regs + S3C_WINSHMAP);
shw &= ~(S3C_WINSHMAP_PROTECT(id));
writel(shw, ctrl->regs + S3C_WINSHMAP);
}
dev_dbg(ctrl->dev, "[fb%d] start_addr: 0x%08x, end_addr: 0x%08x\n",
id, start_addr, end_addr);
return 0;
}
Unfortunately for use, this seems to use DMA transfers. The driver sets the start and end addresses for the hardware to automatically transfer the data to the registers representing the GPIO. The only way I can think of to modify this behavior is in this sequence:
1. Create our own "framebuffer" (or double the size of the current framebuffer)
2. Mix colors from the original buffer and write it to ours
3. Repeat every new frame
4. Point the DMA transfer source to our framebuffer instead of the original
Quite a complex process I think... I'm not even sure if its worth the development effort.

nightsky87 said:
Ironically, register definitions don't seem to be in those files. They probably used a different set of defines. What I did find was this in /drivers/video/samsung/s3cfb_fimd6x.c:
Code:
int s3cfb_set_buffer_address(struct s3cfb_global *ctrl, int id)
{
struct fb_fix_screeninfo *fix = &ctrl->fb[id]->fix;
struct fb_var_screeninfo *var = &ctrl->fb[id]->var;
struct s3c_platform_fb *pdata = to_fb_plat(ctrl->dev);
dma_addr_t start_addr = 0, end_addr = 0;
u32 shw;
if (fix->smem_start) {
start_addr = fix->smem_start + (var->xres_virtual *
(var->bits_per_pixel / 8) * var->yoffset);
end_addr = start_addr + fix->line_length * var->yres;
}
if (pdata->hw_ver == 0x62) {
shw = readl(ctrl->regs + S3C_WINSHMAP);
shw |= S3C_WINSHMAP_PROTECT(id);
writel(shw, ctrl->regs + S3C_WINSHMAP);
}
writel(start_addr, ctrl->regs + S3C_VIDADDR_START0(id));
writel(end_addr, ctrl->regs + S3C_VIDADDR_END0(id));
if (pdata->hw_ver == 0x62) {
shw = readl(ctrl->regs + S3C_WINSHMAP);
shw &= ~(S3C_WINSHMAP_PROTECT(id));
writel(shw, ctrl->regs + S3C_WINSHMAP);
}
dev_dbg(ctrl->dev, "[fb%d] start_addr: 0x%08x, end_addr: 0x%08x\n",
id, start_addr, end_addr);
return 0;
}
Unfortunately for use, this seems to use DMA transfers. The driver sets the start and end addresses for the hardware to automatically transfer the data to the registers representing the GPIO. The only way I can think of to modify this behavior is in this sequence:
1. Create our own "framebuffer" (or double the size of the current framebuffer)
2. Mix colors from the original buffer and write it to ours
3. Repeat every new frame
4. Point the DMA transfer source to our framebuffer instead of the original
Quite a complex process I think... I'm not even sure if its worth the development effort.
Click to expand...
Click to collapse
Well, i need a new challenge

bedalus said:
Well, i need a new challenge
Click to expand...
Click to collapse
Great then! Good luck!!
...just kidding
The way I see it, it might not be that hard after all. The way the code is structured, seems to show that you can just retain most of the fb routines. They mostly describe stuff like offsets, dimensions, and the like. If you copy the ENTIRE framebuffer into another memory location and manipulate that, you won't have to concern yourself with the rest of those functions. Yeah it uses up about 17 MB more of precious RAM (if my calculations are right) but at least you only have to set the DMA addresses instead of recoding a lot of things.
Before anything, can you somehow check which files in the /drivers/gpu/ folder are being used/compiled? I think I may see something useful in those files but I'm not sure if its even relevant.

[KERNEL][GPL][4.2.2][July 10][b10] m_plus kernel for mako

m_plus kernel for Nexus 4 (mako)!
Hi all, since _motley has been MIA of late and his work was my favorite kernel for the Nexus 4, I have decided to continue his work in his absense. As a result much of this thread will look very similar to _motley's original thread here: http://forum.xda-developers.com/showthread.php?t=2021437. I would like to personally thank _motley for his work and dedication to this project, I only hope I can keep his loyal users happy in his absence.
Disclaimer: As usual, I am not responsible for anything that may or may not happen to your device as a result of using this kernel or any other flashable zips posted by me in this thread.
Features
Highly customizable with scripts. See post #2 for all the tuning options.
Google 3.4 base. All stock features are of course supported (camera, NFC etc.)
Compiler optimizations (-O2 + others) - using 2012.12 Linaro toolchain
Full ramdisk install with init.d support for stock/AOSP (CM already has support, for stock you must install busybox!)
CPU Overclock steps 1.56, 1.62, and 1.67GHz (default freq is still stock on boot, OC is optional)
304MHz lowest CPU freq step added with lower voltage than stock, since the device spends a lot of time at this frequency.
Safe UV by default for nominal, fast, and faster binned chips.
Voltage control - be careful to not save the setting on boot until you are 100% sure it is stable! (thanks faux123! + my tweaks)
In-kernel auto_hotplug (thanks to thalamus). I have added and exposed all the tuning parameters and a debug mode to userspace.
Customized in-kernel thermal solution smart scaling, dynamic polling, and configurable throttle temp.
Custom PowerHAL module (spam-free Android log from PowerHAL events)
Controllable touchboost frequency and duration
Gamma and Sound control (thanks faux123!)
Fsync control (3 modes)
USB Force Fast Charge
I/O schedulers - SIO(optimized), deadline (optimized), row, cfq, noop, and fiops
TCP Congestion Control (several choices available) - veno is the default
Governors - Interactive (default), OnDemand, PowerSave, Conservative
CIFS, NFS, NTFS r/w, TUN - built-in, no need for any kernel modules
Other misc patches and tweaks (see github link at the bottom of this post)
GPL compliant - source is kept up to date at github.com and released at the time the kernel is released to the public via this post. Demand that other devs do the same!
Requirements (please read carefully and visit the other dev threads as necessary)
Boot-loader must be unlocked and you must have a custom recovery installed (CWM or TWRP).
Have your ROM zip on your /sdcard so you can restore your whole ROM if necessary.
Do a complete backup using custom recovery so you can restore your boot.img and ROM if necessary!
System Tuner is recommended for monitoring/tuning the CPU, especially for voltage control. Other kernel apps like faux123's will likely work as well, but they have not been tested.
AOSP ROMs including stock - for init.d support, you must have a working busybox install in /system/xbin.
Installation
Check the requirements above and read release notes below for the build # you are installing for any extra instructions!
If coming from another kernel, read the instructions in red below and follow them before flashing.
Flash the the kernel zip using your custom recovery.
Optional: if you want to revert back to what you had, restore your backup of your boot.img in recovery. Another option for reset back to stock is to flash the stock reset zip above. For other custom ROMs, dirty flash your custom ROM in recovery to get your default kernel and ramdisk back.
If you have issues and are coming from another custom kernel or ROM, follow these instructions first before the install. Many custom kernels are changing the ramdisk or other binaries that require a reset before moving back to stock or another kernel.
Reset for Stock ROM - flash this reset package that includes the stock kernel, ramdisk, thermald, mpdecision, and PowerHAL binary. This can also be used if you are using the stock ROM and want to go back to stock.
Download - N4_422_stock_kernel_and_components.zip
MD5 - f801fc7702e29d85447e9b6fdc880549
Reset for any non-stock ROMs like CM, AOKP etc - dirty flash your current ROM or nightly zip then your gapps in recovery (just flash, no wiping). This will give you back your original ramdisk, kernel, and other binaries that other kernel devs may have tweaked, renamed, replaced etc.
Builds
Personal Request: If you plan to make unofficial builds with features not included in the builds posted by me, please don't link them in the thread, all this does is result in confusion especially if someone has a problem with something you have added, it is much easier for me to provide support if I know that everyone in the thread is running the same builds I am. If you want to make a kernel with these features, feel free to start another thread so that they can be discussed and supported as appropriate.
Current Buildbot Status:
Source: https://github.com/thracemerin/kernel-Nexus4
As with _motley's builds, the stable version will be a base build which includes the ramdisk and other component binaries to make the kernel work as expected, you will need to flash the stable version prior to flashing any experimental versions or something may not work as expected.
All files are now available from goo.im: http://goo.im/devs/thracemerin/mako/m_plus
Note: Due to goo.im file naming rules I had to change the name of the zip to m_plus from m+, this has no effect on the content, the ones on goo.im are identical to those that were on dev-host other than the names.
Change Logs
Note: The builds below are for 4.2.2 only, for the latest 4.3 alpha builds check the last few pages of the thread. *4.3 builds will appear on goo.im when they are closer to being official production builds.
This thread is for 4.2.X versions only, use the following threads for 4.3:
JW Builds: Thread not available yet, Alpha 3 is still here: http://forum.xda-developers.com/showpost.php?p=43993185&postcount=860
JS Builds: http://forum.xda-developers.com/showthread.php?t=2385840
Build 10 (Exp) - July 15, 2013
Note: You must be on Build 1 or later. (Build 8 if you are on MIUI)
Various patches to the kernel to prevent out of bounds access to memory (see github for details)
Added sweep2wake, it is disabled by default, see post 2 for info (thanks to show-p1984)
Added a patch to fix some unusual behavior with the LEDs (thanks to CM)
Build 9 (Exp) - July 3, 2013
Note: You must be on Build 1 or later. (Build 8 if you are on MIUI)
Added the simple GPU governor for Qualcomm Adreno GPUs thanks to Faux123 (set as default, no need for the script required in the Alpha). Tunables explained in Post 2.
Build 8.1 (Exp) - June 20, 2013
Note: You must be on Build 1 or later. (Build 8 if you are on MIUI)
Actually reverted some of the msm_hsic patches because they seem to cause data drops (I only pretended I did in Build 8, oops )
Build 8 (Exp) - June 18, 2013
Note: You must be on Build 1 or later.
Reverted some of the msm_hsic patches because they seem to cause data drops
Now build with the Linaro 4.8.2.2013.06 toolchain
Switched the allocator from SLUB to SLAB because SLUB wouldn't boot when compiled with 4.8
Various fixes to allow building with 4.8
Build 7 (Exp) - May 26, 2013
Note: You must be on Build 1 or later.
goo.im seems to be a little flaky this afternoon, alternative downloads here: http://forum.xda-developers.com/showpost.php?p=41865828&postcount=416
Patches to freezer from Colin Cross
More patches to workqueue from CAF
Patches to the cpufreq driver from CAF
Reverted lowest frequency step to 384MHz (See Post 3 for why)
Fixed board-mako-regulator.c to allow for UV to work (Warning: Reset your UV settings if you have UV below 850mV, if you flashed the previous alphas this is probably not necessary.)
Reset undervolting to stock from Google, just in case the above causes problems for new adopters (You still have full access to undervolt to 600mV if your chip can handle it)
Added the change pointed out by veyka here: http://forum.xda-developers.com/showpost.php?p=41730297&postcount=380
Some more patches to the hsic controller that were in my other project but not this one.
Build 6 (Exp) - May 19, 2013
Note: You must be on Build 1 or later.
CAF changes to cpufreq
CAF changes to workqueues
Build 5 (Exp) - May 12, 2013
Note: You must be on Build 1 or later.
CAF patches to block.
CAF patches to the charging and battery management system.
CAF patches to the video driver.
Build 4 (Exp) - May 5, 2013
Note: You must be on Build 1 or later.
A few more sched patches from CAF
Patches to android lowmemory killer from CAF
Headphone poweramp controls (thanks to Faux123)
Build 3 (Exp) - May 3, 2013
Note: You must be on Build 1 or later.
Various sched patches that were in _motley's 4.2.1 kernel and not his 4.2.2 kernel
FIOPS i/o scheduler is back
192mhz frequency step added (thanks to showp1984)
Note: The ramdisk currently forces the minimum to 304mhz so i added an init.d script to force it to 192mhz so I didn't have to redo the ramdisk.
I'll fix this in the next base build.
If you still want to use 304mhz as your lowest step, see post 3 for details on how to do this.
Note 2: The voltage is the same as the one _motley used for 304mhz for stability reasons, it will still use less power, but feel free to uV it if you like.
Build 2 (Exp) - April 30, 2013
Note: You must be on Build 1 or later.
Update ROW i/o scheduler to the latest from CAF, now default i/o scheduler
FIOPS i/o scheduler was removed because _motley added FIOPS and ROW as 1 commit and messing with ROW screwed it up.
Hardcode ROW magic values (thanks to franciscofranco & osm0sis)
Update interactive governor to the latest from CAF (it may be a little less aggressive)
Krait Retention (thanks to CAF, faux123)
Build 1 (Base) - April 29, 2013
Everything from _motley's b49 build up to this point.
Built with the linaro 2013.04 gcc-4.7 toolchain
Thanks
Google - For AOSP sources
LG - for building the N4
Qualcomm/CAF - for their updates to the N4 kernel
_motley - for all his work on this kernel
faux123 - patches included that were initially written by him
franciscofranco - patches included that were initially written by him
showp-1984 - patches included that were initially written by him
anyone else i've neglected to include, if you feel you deserve to be thanked by name by all means PM me

Tunables should be the same as _motley's kernel so I'm quoting him here:
(All the tunables that are discussed in _motley's thread http://forum.xda-developers.com/showthread.php?t=2021437 should work the same way on this kernel)
_motley said:
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.
Code:
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:
Code:
#!/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.
Code:
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
Code:
#!/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.
Code:
echo 1 > /sys/devices/platform/mipi_lgit.1537/refresh_screen
Presets:
Code:
#!/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
Code:
#!/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
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
Code:
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
Code:
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
Code:
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:
Code:
echo 1 > /sys/kernel/fast_charge/force_fast_charge
Turn OFF:
Code:
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)
Code:
/sys/devices/system/cpu/cpufreq/interactive/boostpulse_duration
What freq does it boost to?
Code:
/sys/devices/system/cpu/cpufreq/interactive/hispeed_freq
Turn touchboost OFF/ON (in b10 and b14 only)
Code:
/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):
Code:
/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).
Code:
/sys/module/msm_thermal/parameters/min_freq_index
Turn on thermal debugging so you can see what is happening in the kernel log:
Code:
/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
Code:
/sys/module/auto_hotplug/parameters/debug
Load at which a CPU is taken offline, 40-125, default 80:
Code:
/sys/module/auto_hotplug/parameters/disable_load_threshold
Load at which an extra CPU is put online, 130-250, default 200:
Code:
/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):
Code:
/sys/module/auto_hotplug/parameters/enable_all_load_threshold
Sample rate in milliseconds, converted to jiffies at runtime, 10-50ms, default 20:
Code:
/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):
Code:
/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):
Code:
/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):
Code:
/sys/module/auto_hotplug/parameters/min_online_cpus
Vibration Intensity
You can also use Trickster MOD to set this.
Example increase intensity:
Code:
echo "90" > /sys/class/timed_output/vibrator/amp
To go back to stock:
Code:
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.
Code:
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.
Click to expand...
Click to collapse
C State Information
(thanks to faux123 - more info here: https://plus.google.com/109078966818501160423/posts/9R8fjQdHDXD)
faux123 recommends C0, C1 and C3 here: http://forum.xda-developers.com/showpost.php?p=40151528&postcount=9775
C0 (WFI) - Shallowest Sleep (default enabled)
Code:
enable: echo 1 > /sys/module/pm_8x60/modes/cpu0/wfi/idle_enabled
disable: echo 0 > /sys/module/pm_8x60/modes/cpu0/wfi/idle_enabled
C1 (Retention) - slightly deeper sleep
Code:
enable: echo 1 > /sys/module/pm_8x60/modes/cpu0/retention/idle_enabled
disable: echo 0 > /sys/module/pm_8x60/modes/cpu0/retention/idle_enabled
C2 (Stand Alone Power Collapse) - deeper sleep
Code:
enable: echo 1 > /sys/module/pm_8x60/modes/cpu0/standalone_power_collapse/idle_enabled
disable: echo 0 > /sys/module/pm_8x60/modes/cpu0/standalone_power_collapse/idle_enabled
C3 (Power Collapse) - deepest sleep
Code:
enable: echo 1 > /sys/module/pm_8x60/modes/cpu0/power_collapse/idle_enabled
disable: echo 0 > /sys/module/pm_8x60/modes/cpu0/power_collapse/idle_enabled
Simple GPU Governor Tunables
Code:
/sys/module/msm_kgsl_core/parameters/simple_laziness
Laziness: Adjusts the number of times the governor skips ramp down requests. (Higher = better performance, higher battery drain)
Code:
/sys/module/msm_kgsl_core/parameters/simple_ramp_threshold
Threshold: Adjusts the threshold to ramp up or down the GPU frequencies. (Lower = better performance, higher battery drain)
To enable sweep2wake:
Code:
echo 1 > /sys/android_touch/sweep2wake

Frequently Asked Questions
Q: You gave us 192Mhz, now you removed it and set 304Mhz back to 384Mhz, why?
A: Good question, there had always been some speculation in this thread and others that frequencies below 384Mhz were not in fact being set correctly, show-p1984 managed to run his device at 27Mhz with no stability issues (this should be impossible) so we did some quick and rather unscientific benchmarking in this thread and found that there didn't seem to be any difference in CPU performance between 192Mhz and 304Mhz (and there should have been), I then speculated that 304Mhz was also not being set, after a little more unscientific benchmarking I determined that there was no difference in performance from 304Mhz to 384Mhz either, so based on this I don't see any reason to allow these frequencies.
Q: I don't want to use the 192mhz frequency, how can I disable it? (Build 3-6)
A: One of the four options below will fix it:
You can delete my script, it's located at /system/etc/init.d/01cpu and reboot, this will set you back to 304mhz minimum.
You can remove it from the zip file (same location in the zip hierarchy) before you flash.
You can use your favorite kernel tuner (trickster, fauxclock, etc...) to switch the minimum frequency back to 304mhz and set it on boot.
You can change the /system/etc/init.d/01cpu script to set whatever minimum frequency you want (it has to be a valid one from the table)
Q: If the 192mhz and 304mhz steps use the same undervolt settings, how can 192mhz use less power?
A: The formula for power consumption is: P = f * c * V ^ 2
Where: P = power consumption, f = frequency, c = capacitance and V = voltage
So: since c is constant in this case, and we'll assume you've used the lowest UV possible (600mV)
At 304mhz: P = 304 * c * 600 ^ 2
At 192mhz: P = 192 * c * 600 ^ 2
This means that 304mhz uses approximately 1.58 times more power than 192mhz over the same time.
Q: There are a bunch of fixes for the delayed notification issues in various threads, what should the settings be for this kernel?
A: The following values should be set in your /system/etc/wifi/WNCSS_qcom_cfg.ini (depending on your ROM you may have different values), these are the Google stock values and appropriate for this kernel.
Code:
McastBcastFilter=3
HostArpOffload=0
gEnableSuspend=3
You can set these values by flashing this: wlan_revert.zip - MD5 - 381013687035626bcb1cbaf609ea4311
Q: Does this kernel include the ARP offload patch?
A: No, and for those of you following my other thread here: http://forum.xda-developers.com/showthread.php?t=2102986 you will know that there is an issue where our WiFi chip responds to ARP requests with a bad MAC address during deep sleep, this results in problems with direct connect (WiFi direct, AirDroid, etc...) and can cause issues with certain types of routers and networks that do not cache ARP addresses for long, as a result I no longer use it in my other kernel either. I am using a different solution which solves the problem for me and many others but has a slight battery life hit, I will post a flashable zip to modify the binaries to include this fix at a later time, but for now if you wish to include this fix do the following.
Code:
open /system/etc/wifi/WNCSS_qcom_cfg.ini in your favorite file editor
find the line that currently reads gEnableSuspend=3
change the line to read gEnableSuspend=2
save the file
reboot your device.
Q: I flashed this kernel and my battery life sucks! WTF?
A: Clearly I didn't design this kernel to drain your battery (nor did _motley) and in my experience most battery drain issues are app related and not kernel related. In order to help me help you solve the problem, please download Better Battery Stats either from the Play Store (costs money, but I strongly encourage supporting the dev) or the free version from XDA and provide me with a dump file for a few hours of use so I can see what is going on with your device, if you don't do this I will assume the battery drain is your fault and will ignore your complaint.
Q: Can you add feature x from kernel y?
A: Maybe, I'm not going to take this kernel and stuff it full of every single idea anyone has while lying in bed trying to fall asleep, but if the feature seems like something that most would use and it's in a reasonable state of working (ie. not something that someone else just started working on) then I will consider adding it, absolutely no promises in this regard.
Q: I got a random reboot, SOD, other bug that must be kernel related, what do I do?
A: Provide me with appropriate logs (dmesg, logcat, last_kmsg (see my sig)) and instructions on how you caused this if possible, if I can't reproduce the issue and I can't see it in the logs there is nothing I can do. Be as detailed about what you were doing at the time it happened, more information is always better than less.
Q: If _motley comes back what will happen with this project?
A: Well, I don't want to step on any toes here, this was originally _motley's work, what happens to it long term if he returns will ultimately be up to him. If he wants to continue from where he left off and merge his own changes beyond b49, I may keep going as a separate project, if he wants to fork me and continue from the point I'm at when he returns that's ok with me too and I'd probably stop if that were the case, but we're speaking in hypotheticals here, anything is possible.
Q: Touch control doesn't work! Why not?
A: Touch control requires a module that is compiled by the author and provided as a pre-compiled binary. I'm not specifically looking to break it's functionality, but changes I make may cause it to stop working at any time between releases, the only way to get this fixed is to speak to the author of the addon and have him recompile the module. If he needs my assistance with anything specific to this kernel, I will do my best to help him out.

Pre-release (Alpha) Builds
These builds are the latest builds produced by the buildbot from the wip branch.
WARNING: These builds should be considered alpha, may contain a lot of bugs, may be unstable, and may be partially or completely non-functional. That being said, I am usually running these builds so if they are really badly broken I'll remove them ASAP.
http://goo.im/devs/thracemerin/mako/m_plus/wip
Current Buildbot Status:
Current Alpha: None, use Build 10!
What's changed:

Thanks for continuing Motleys kernel, waiting for links to download and flash.

Build 1 is up, happy flashing :victory:

Thank you very much for the kernel, I'm glad to see the motley's great work doesn't get forgotten.
PS: a benchmark for the ones that like it, stock settings and sabermod rom.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

I hope _motley is alright. Thank you for continuing to develop this great kernel in his absence.
Will you be including the new Prima drivers and retention patches introduced by kszaq to fix some of the wifi problems? I know it's not a solution for everyone, but I personally thought it worked well with no battery hit and some others seem to agree.
Anyway, thank you for your work and good luck with _m+ .

mko000 said:
I hope _motley is alright. Thank you for continuing to develop this great kernel in his absence.
Will you be including the new Prima drivers and retention patches introduced by kszaq to fix some of the wifi problems? I know it's not a solution for everyone, but I personally thought it worked well with no battery hit and some others seem to agree.
Anyway, thank you for your work and good luck with _m+ .
Click to expand...
Click to collapse
Krait retention, yes.
Prima/ARP Offload, not right now, there is a workaround and better explanation for why in post 3, I'll continue to work on it in my other thread, if I get to a fully working solution, then absolutely. The current issue with the Prima driver makes my phone unusable for something I do on a daily basis which is why I will not do it currently (I want to be able to use this kernel as my daily driver).

Flashed the CM build, all fine thanks! Felt the smoothness of Motleys kernel again.

Very nice! Um, I took a look at your git, but i couldn't work out what you added over b49 heh, mind giving a quick summery?
Sent via Nexus 4

veyka said:
Very nice! Um, I took a look at your git, but i couldn't work out what you added over b49 heh, mind giving a quick summery?
Sent via Nexus 4
Click to expand...
Click to collapse
Nothing atm, this release was just a stable start to move forward on and proof that I had the infrastructure set up to actually build with linaro gcc-4.7. I'll have another release in a day or two with some new stuff
Plus, it avoids having to get people to get b37 & b49 from _motley's thread before moving forward with builds here.

thracemerin said:
Nothing atm, this release was just a stable start to move forward on and proof that I had the infrastructure set up to actually build with linaro gcc-4.7. I'll have another release in a day or two with some new stuff
Plus, it avoids having to get people to get b37 & b49 from _motley's thread before moving forward with builds here.
Click to expand...
Click to collapse
Cheers! So i wasn't being a brainless derp then
Sent via Nexus 4

thracemerin said:
Krait retention, yes.
Prima/ARP Offload, not right now, there is a workaround and better explanation for why in post 3, I'll continue to work on it in my other thread, if I get to a fully working solution, then absolutely. The current issue with the Prima driver makes my phone unusable for something I do on a daily basis which is why I will not do it currently (I want to be able to use this kernel as my daily driver).
Click to expand...
Click to collapse
Hey fellow super android lol nice work with this kernel. I'm gonna give this a whirl and see how it performs. Thanks for continuing motley's kernel.

thracemerin said:
Nothing atm, this release was just a stable start to move forward on and proof that I had the infrastructure set up to actually build with linaro gcc-4.7. I'll have another release in a day or two with some new stuff
Plus, it avoids having to get people to get b37 & b49 from _motley's thread before moving forward with builds here.
Click to expand...
Click to collapse
I guess I'll wait a few more days then
Sent from my Nexus 4 using xda app-developers app

iamhacked said:
I guess I'll wait a few more days then
Sent from my Nexus 4 using xda app-developers app
Click to expand...
Click to collapse
I can push build 2, I just haven't tested it hardly at all and if it blows someone's device up I'd feel bad.

thracemerin said:
I can push build 2, I just haven't tested it hardly at all and if it blows someone's device up I'd feel bad.
Click to expand...
Click to collapse
take your time. dont rush. i know people are chomping at the bit for something new but ignore them.
or post a test build and let us blow up our phones haha :good:

Hi, if I may make a request, do you think it's possible to lower the minimum allowed voltage?
Sent from my Nexus 4 using xda app-developers app

Logi_Ca1 said:
Hi, if I may make a request, do you think it's possible to lower the minimum allowed voltage?
Sent from my Nexus 4 using xda app-developers app
Click to expand...
Click to collapse
It's 600mV right now, correct?

Yup, it's 600mv now. I was thinking that since the phone spends most of its time at 384mhz, and for me that frequency is totally stable at 600mv, it's probably possible that the voltage at 384mhz can go even lower. However I noticed that most of the other kernels have higher minimum allowed voltages, so there may be a reason for that that I'm not seeing here.
Sent from my Nexus 4 using xda app-developers app

Nexus 5: All color related things! (FAQ, Calibration Guide, Development)

Nexus 5 Calibration:
Welcome to this thread: This thread is all about colors and displays. Nexus 5 only though!
- “Easy part: Apps, profiles” is for those that just want to mess around with some of the user created profiles and then move on. You can find the frequently asked questions about the profiles here!
- “More technical part” is for those who are more interested in this topic. Reading this part is recommend before calibrating.
- “Calibration” is for those who want to create a profile themselves (requires colorimeter or spectrometer).
- “Testing without a colorimeter” is for those without a colorimeter, but are still anxious to mess around ^^
- “Current state of development” shows the questions we don’t know the answer to yet.
Click “Click to show content” to extend the information!
Easy part: Apps, profiles
How do I get a color calibration app?
Make sure you have a compatible kernel first, like Franco's
Either use:
Nexus Display Control (Free)
FKU (paid)
Faux123 Kernel Enhancement (paid)
Kcontrol (paid)
How do I get profiles?
They are pre-installed! Just tap:
FKU: Color Utils - Load a color profile - Import preloaded profiles
NDC: Load a color profile - Import preloaded profiles
Faux: No need to do anything!
KControl: Not available
Newest collection of profiles.
Link 1 (Be sure to give a thanks to @vomer)
Link 2 (Be sure to give a thanks to @The Gingerbread Man)
If you download a new profile, you have to put them in a specific location:
FKU: /franco.kernel_updater/color_profiles
NDC: /nexus_display_control/color_profiles
Faux: /com.teamkang.fauxdisplay/profiles
After this, you can select and apply the profile.
How do I apply a profile?
Nexus Display Control App or Franco Kernel Updater App:
1) Tap 'Load a color profile' (Under color utils in FKU)
2) Select your profile
3) Hit Apply
4) Turn screen off and on to view result*
FauxClock:
1) Color/Gamma – Gamma Profiles
2) Select your profile
3) Hit Apply
4) Turn screen off and on to view result*
KControl: Not available
* On some kernels not required
Which profile is the best?
There is no best profile unless you buy a colorimeter. Here is why:
Every display is different, so the profiles that are perfect for one display will probably not be as perfect on your display.
Everything is subjective: You might like a more blueish screen, you might want accurate colors. All depends on you what is perfect
Even if you have a seemingly perfect profile, you can't test it without a colorimeter
How do I test my profile?
This is a tricky question. I have tried to develop ways to test a profile without the use of a colorimeter and I failed. It's impossible. You will never know the exact gamma, color temperature, etc etc.
There are things you can test however! Move on to part: Testing without a colorimeter!
But if you do have a colorimeter, check out: Calibration (requires colorimeter)
I love this profile. How do I set it as standard?
Check the checkbox 'Set colors on boot' in the app. (It’s a slider in FauxClock)
Problems:
Help I screwed up! How do I revert?!
Rebooting the device resets the display to stock settings (unless you ticked ‘Set on Boot’)
Or load up the stock profile (in attachments below).
(If the previous don’t work, your issue is more severe. Reflashing kernel, rom should work. If not, you have a hardware issue. Google for more info or RMA)
I don't see any difference! Why?
1) Do you have root and is root applied to the app?
2) Did you turn your screen off and on?
3) Note that the differences can be small.
4) Clearing app data and cache can do magic.
If none of these solutions work, verify that colors do change with the profile "Test your settings" (Download below)
If the profile and app work, you should get a very blue screen. (Revert by rebooting or loading other profile)
If the profile doesn't work, please search thread first, then ask questions. Your question has most likely been answered already!
The app doesn't work! :crying::crying:
1) Verify you are using a compatible kernel! Franco/Faux/Elementalx are all compatible. There are certainly more compatible kernels. Just check in that kernel thread if the kernel is compatible.
2) Verify that you have root and that the app gets root.
Please search the thread before posting! Usually your question has already been answered 5 times.
If I want to load a profile, the app force quits. Help!
The profile is invalid. Redownload it or use another profile. If this doesn’t work, try clearing data and cache of the app.
More technical part: Gamma, color temperature and colorimeters
Definitions you must at least heard of
Luminance
Luminance is a photometric unit to describe the amount of light coming from the screen. It is usually measured in cd/m2 (also called nits). It is comparable to brightness, but brightness is the perceived luminance (so subjective luminance you could say). Example: A display with a luminance around 100 nits is not so bright in the sun, but very bright in the dark. The luminance in both examples is the same, while the perceived brightness is not.
Gamma
The eye has a non-linear response to light. To correct this, gamma correction is applied.Without doing this, images look too light. Increasing gamma, means increasing the saturation. More info
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Color temperature
Color temperature is basically a measure of the color hue of white light that is measured in Kelvin (K). When you increase the color temperature, the hue becomes more blueish, decreasing it will result in a more yellowish/reddish screen.
RGB
When you are looking at a digital image, you are looking at a lot of pixels that make up this image. Each of those pixels consists out of a three sets of RGB numbers. These numbers can range from 0 (black) to 255 (white). For example: 255,255,255 will produce white, whilst 255,0,0 will produce red. RGB values themselves do not say much. You have to tell in what colorspace there are. These different colorspaces have different gamuts. Webcontent and our display use sRGB.
Here is a RGB color mixer to get a grasp on RGB.
More info on gamuts
Saturation
The vividness of a color. This can range from black/white to neon like colors.
Contrast ratio
The contrast ratio is the ratio between the brightest color (white) and the darkest color (black) your display can produce. Our Nexus 5 displays usually have around 920 (based on various measurements I have seen).
Useful links for more information:
Wikipedia:
Luminance
Gamma
Color Temperature
RGB
Gamut
Saturation and more
Contrast Ratio
Cambridge in color
GammaFAQ by Charles Poynton (expert) (Might be a bit outdated as 1998)
ColorFAQ by Charles Poynton (expert) (Might be a bit outdated as 1998)
Some color math by Bruce Lindbloom
Saturation vs. Vibrancy (vid)
How LCD works (hardware)(vid)
What do the parameters mean?
In total there are 24 parameters (of which 23) are displayed. Each parameter controls the luminance of a part of the RGB range. All other aspects (gamma, color temperature, saturation, contrast ratio) are derived from that. As stated, each parameter controls a portion of the range. Shown in this image are the ranges:
Note that the ranges do overlap in certain values. This means that one RGB value can be controlled by two parameters. (But never three!)
Let's take parameter 11 as an example: Parameter 11 has a range of 144 to 202. These RGB values can be altered by altered parameter 11. Most affected by parameter 11 is RGB(175). This RGB value will change the most when altering parameter 11. Respectively, RGB(144) and RGB(202) will change the least.
Negative and positive?
Also you might have noticed, there are two arrays for red, two for green and two for blue. Why? It’s for more precision:
These two arrays get combined to form one resulting figure. It’s not as simple as 10 and 20 become 15. Therefore I recommend keeping the difference between the parameters small in order to avoid confusion. Also the negative and positive are not equal. 10 & 20 do not produce the same outcome as 20 & 10.
Overall it’s best to keep the same when calibrating initially. But when you need a certain luminance you can’t achieve when they are the same, divert them. This method works the easiest and you don’t lose track of your changes so easily.
The White Point
The White Point is an odd setting. It does not control the color temperature in any way, form of shape. It’s also highly doubtable that the LG devs ment the white point in the curves adjustment tools of Photoshop. Currently the exact function of it is unknown, but what we know is the following:
Although the range can be 0 to 255, it actually ranges till 63. After that it loops. (0=64=128=192 and 63=127=191=255)
It’s main purpose is to allow more control over the RGB curve. Instead of controlling ranges of RGB curves, the White Point is an overall setting that adjusts every channel and every RGB value.
The recommend setting is between 29 and 33 and the middle value is 31
What would be the ideal settings?
When you capture an image with a camera, you want to see the same colors on your screen as the colors in real life right? Well, that is called an accurate screen.
Though, a lot of manufacturers don't provide accurate colors. Why not? Because the masses like punchy colors with a higher color temperature. The truth is that we have become accustomed to those colors. An accurate display seems a bit yellow nowadays. But there is a way out! Once you experience a true accurate profile, the other profiles seem really blue. Like all the things in life, we get accustomed to it.
An accurate profile would contain:
Banding: None
Color Temperature: 6500K
Gamma: 2.2 - 2.4
Properly saturated colors (Automatically achieved with calibrated gamma)
Contrast ratio: Higher is better, but above 930 is already pretty good for our LCD displays
How accurate is stock?
Actually, stock is quite accurate in comparison to other phones. There is certainly room for improvement, but they definitely tried to calibrate our screen correctly. The color temperature is around 6500K (+- 300K). Gamma is a bit too low (2.0), but in comparison to other phones it is quite good.
I like the punchy colors, can I keep them?
Of course! Your display, your rules. Having a higher color temperature isn't necessarily bad, though you must compensate a little bit. The changed settings would:
Color Temperature: 7500K
Gamma: 2.3 - 2.5
Note that for compensation for the higher color temperature, you increase the gamma a bit. This also works the same way around for lower color temperatures. Also, the same things like no banding still apply
Calibration (requires colorimeter)
Requirements for calibration
A colorimeter (Like Xrite i1 Display Pro (recommended by Display Expert Francois Simond))
HCFR
Faux Gamma App or any other app that can edit these parameters (Like Kcontrol or FKU)
Microsoft Excel or any other sheet program (Like Libre Office)
Nexus 5 with compatible kernel
Time
At which brightness should I use to test?
Unless you use autobrightness, I recommend using the brightness you use the most. But, you have to keep using that brightness for comparisons of profiles. So pick a brightness to your likings, but be consistent! (And no auto brightness!). I usually use 100%.
Let’s get started!
Step 1: Preparations
1) Set the screen timeout to 30 minutes or longer.
2) Keep your screen on for 30 minutes at the predetermined brightness. You can use you phone, just don't turn your screen off.
(Your display needs to stabilize by warming up. If you were to measure in the first minute you will see that the results are quite different than after 30 minutes. To ensure proper calibration, one must warm up the screen for at least 30 minutes)
3) Make sure you have all the requirements listed above. Also download “Shades of Grey” to your phone and “Display Calibration Nexus 5 by yorici.xlsx” to your pc.
4) Extract the images from the file explorer to a folder on your phone. There are multiple versions. I suggest reading further first, but if you can’t wait, extract “Shades of Grey (Recommended).zip”
5) Connect your colorimeter to your pc and open up HCFR.
6) In HCFR: Press 'new' - Select 'View images' - 'Next'
- Then under 'Select a sensor in this list': Your colorimeter (Can be any name). Do not use a meter correction file unless you know what you are doing. - 'Next'
- Display Type: 'LCD White LED IPS' - Reading Type: 'Display' - OK
7) In HCFR: Go to Free Measures and make sure you have set the mode in RGB
Test if it works by pressing F7. It should have measured once now and you get a table of data with one row. If you click on it, you will see more data in the left pane below.
8) If your screen hasn't warmed up for 30 minutes now, just play a game or do something else. It might be useful to get a charger as you will have your display constantly on for the rest of the steps.
Step 2: Set the goals
It is up to you what color temperature and gamma you want. I suggest you first read "More technical part: Gamma, color temperature and colorimeters" first before beginning with this. The accurate settings are there too. It's up to you how you want to calibrate though. These are my tips you should keep in mind:
Red is the limiting color in our display. Try to keep it maximised and play with blue and green
The blacks can be harder to calibrate. Try to aim for an accurate gamma though. Color temperature is less of importance because you won't see blue or red blacks as good as you would see blue whites or blue blacks.
Always turn screen off and on after editing parameters. No changes will occurs if you don't!
As you will have to turn off your screen a lot, it might be easier to temporarily disable your lockscreen. This can save some time.
Step 3: The first parameter
1) Open the Shades of Grey folder with a Gallery App (I prefer QuickPic)and just open the first image (begins with “a RGB(255,255,255)....”). These images are sorted in the right order, you will only need to swipe.
2) Do a 'Free Measure' by pressing F7. I do usually three times for more accuracy:
Those three results I combine in one value with less decimals (usually 1). You will always get three different results, so you can't use just one of them. You will need to average them out. This creates uncertainty and therefore you remove two decimals. (If you get three times the same result, please keep it to one decimal. It's very unlikely you will get three times the same results another time)
3) Note these values in max luminance in the spreadsheet
4) Measure the second image (black) and note these values in min luminance. When you edit them, you will see the other values change.
5) It will probably the case that the first two values aren't resulting in your desired goals. Now you must correct this by editing the parameters. Open up Faux Gamma App (or any other app that can edit the parameters like FKU or Kcontrol)
6) Let's say I want to achieve 6500K. For that to happen, every color channel needs to result in the same value. Lred=Lgreen=Lblue.
In my previous result: Blue and green were higher than red. Red was maxed out, so I need to decrease blue and green
In Faux Gamma App (and Kcontrol) the first 12 parameters are reversed: Increasing parameters will decrease colors
In FKU this annoyance is removed: If you increase any parameter, the corresponding color will always increase
To decrease blue and green for the first value, I need to increase the first parameter in Faux Gamma App and decrease in FKU. Pay attention to which parameter you are editing. The 13th to 23th parameters are normal.
How much you should adjust is not determined. The only thing you know is that when you have a difference of 5 in luminance (Desired vs. irl), the adjustment in the parameters should be less than when the difference is 50.
7) In general this applies: The more accurate each parameter was calibrated in relation to the next parameter, the better the gamma.
The more accurate each color channel (Red, green and blue) was calibrated in relation to another, the better the color temperature.

Step 4: The rest of the parameters
1) When you are done calibrating the first parameter, continue to the next parameter. I usually start by calibrating all red, then green and finally blue.
2) In the Gallery, swipe to "c - p(2) - RGB(254,254,254)". This means parameter 2 (the c is for the right order in gallery apps). Measure this three times and take average.
3) Swipe to "ca - RGB(255,255,255)". Measure it three times and take average. This is max luminance again.
4) (Optional for parameters 1 – 14) Swipe to "cb - RGB(0,0,0)". Measure it three times and take average. This is min luminance again.
5) In the spreadsheet: Fill in max and min luminance. Then compare the first average of p(2) with the suggested value of parameter 2 in the spreadsheet.
6) Adjust accordingly in Faux Gamma App, Kcontrol or FKU. Screen off/on! And repeat substeps 2 to 5 until desired value = p(2) value.
7 - 99) Repeat for every other parameter.
PRO TIP: Save your work every 6 parameters! Just save it as a profile. When you reboot, you might lose your progress as the default profile is stock.
Temporarily get rid of your lockscreen. Unless you use Faux Kernel, you will need to turn your screen off and on a lot. Removing the lockscreen will ease that a bit and save you time!.
NOTE: If you want to save some time, you can skip measuring blacks (cb - RGB(0)..) every time. Just measure it fifty times with F8 mode while moving the colorimeter over the screen. Take average of those and keep it at those. You should get “Shades of Grey (No blacks).zip” then. It is better to measure black for 15 to 23 though!
Step 5: Review the results
1) Get Voodoo Screen Test Patterns App (free)
2) Open the app and set the amount of measurement points in the settings. [More=better, but more difficult]
3) Set the equal amount of measurement points in HCFR: (I use at least 25, b/c 24 parameters)
HCFR – Measures – Parameters – Number of Grayscale levels
4) Press “GO” and it will show images on your PC. You have to press next on your phone to keep up with the images.
NOTES: It’s a bit wonky and you should take multiple attempts at this for more accuracy
If calibration is done correctly, the color temperature should be around 6500K (+- 75K). The average gamma should be very close to your setting. The gamma line itself can be a bit squigglier, but keep it around the gamma you have chosen earlier.

Step 6: Share and contribute!
Please share you final product of hard work!
1) Save your profile using the Nexus Display Control app (FKU has this functionality too).
2) With a file explorer navigate to nexus_display_control/color_profiles and locate your profile.
3) Gather results from HCFR (right-click - save): gamma and color temperature (with saturation, luminance, near white, near black you are even better ;P)
4) Claim your glory and post the profile, HCFR images and you goals (which gamma and color temperature were you going for?) in this thread as a reply!
If you are really satisfied with the result, please consider buying me a beer I have done a lot of research to get to these results and they have all been done in spare time.
Testing without a colorimeter
Most of the users don’t have a colorimeter and you might not either. What can you test?
Banding: Less accurate, but still possible, you can check banding! By using gradient you can review the smoothness of the gradient. I have included gradients that are capable of doing this! You are looking for sudden interuptions in the gradient. If it is good, the gradient will appear smooth without any distortions.
Color Temperature: Though, incredible inaccurate and very biased, you can check color temperature subjectively. I do not recommend relying on it, but you can see the differences in hue and adjust the parameters. Though there is no way to measure it. I have included gray images that you can use!
You just swipe through the pictures and you will notice the different hues. Though it subjective to judge which one is incorrect…
Gamma: Short answer: No, not really.
Long answer (involves Display Tester App):
Although Display Tester App (and more apps alike) claim to test gamma, their results are biased . The principle the Display Tester App relies on is the following:
You create a background with a grid. The grid is composed of RGB (255,255,255) and RGB (0,0,0). This is the same as 0% and 100% gray. Because the eye can’t see individual pixels, the grid blends to a half tone: 50% gray. If you place a 50% gray block on the background, they should match. Up till this part, everything is correct.
There is one problem: The Display Tester App only tests 50% gray. 50% gray results in RGB (186,186,186). So basically, you are only testing only one RGB value out of 256.
To make this even more fun: The Display Tester App also messed up the background… While it should be a perfect grid of 0 and 255, it actually goes from 0 to 8 and 247 to 255. No, this is not better, it only is more biased. You can’t rely on RGB (1 to 254) as they are not calibrated yet.
If you have used the app, you may have noticed that changing the viewing angle, changes the outcome. The outcome is also dependent on ambient lighting, if the screen has been warmed up for 30 minutes, your eyes, brightness.
With so many variables you can’t believe this app will produce any reliable result… Even if it did, it would only count for RGB (186).
My advice: Do not rely on the Display Tester App or any other app that claims to be able to measure your gamma!
Notes:
- 50% gray = 0.5^(1/2.2) * 255 = 186 (It’s not 127/128 due to gamma correction)
- You can see for yourself that the app is biased: Change parameter 9 (any color) to 255. Open the app: no real difference right? The 2.2 box will remain the same and the background too, while if you look at photographs there is noticeable something wrong! This can’t be right, can it?
Saturation: Forget it.
Contrast: Very complicated process with another camera perhaps. Google is your friend. (It will be quite inaccurate: the camera alters the picture too (white balance))
Color checker cards
You could buy color checker cards and use those to calibrate. It's a bit cheaper.
Disadvantages:
Less accurate than a colorimeter due to inaccuracy of the eye and ambient lighting
Only one calibration possible: 6500K, gamma 2.2
If you are going to spend more than 40 on it, I suggest you buy a cheap colorimeter instead.
Should I use the RGB sliders?
Short answer: No, only for very specific purposes.
Long answer:
The RGB sliders shouldn’t be used if you want to improve your screen. If you want to make your screen all red, the sliders are perfect.
What the sliders to is limit the RGB range. If you set the red slider at 240, RGB(255) will become what normally was RGB(240). Every RGB value gets relocated from there between RGB(0) and RGB(240). You are basically limiting the amount of colors you can display. Not that awesome right? (Unless you want to do this)
Current state of development
Not everything has been uncovered yet:
Can be predicted how much one should increase a parameter to get a certain luminance?
My idea: Let’s assume that an increase of parameter Y with amount X always increases Luminance(Y) with the same amount. Let’s call the screen’s calibration when every parameter is set at 0, the base calibration. That base calibration is different for each display and define the characteristics. When measured correctly, one could calculate how much each parameter should be increased to get the desired luminance.
Explanation needed for the strange behavior of the first 8 parameters when all set to 0.
What is the mathematical connection of the white point in relation to the parameters?
The so called ‘white point’ is the only parameter that can adjust the entire RGB range. What is the mathematical connection between each individual parameter and the white point?
Changelog and credits:
Changelog:
26-5-14: Initial post placed
27-5-14: Fixed link, added color checker cards (Thx Tzfardaya), added white point measurements in post #2
1-6-14: Fixed type, thx @nihil0
16-6-14: Added profile: Yorici_Calibrated_Punch (see second post)
20-6-14: Added more info in FAQ under "How to get profiles?"
Immense thanks to:
@supercurio, @myfluxi, @faux123, @franciscofranco, @mag01, @rajendra82, @gpvecchi, @Tzfardaya, @granets, @tkoreaper, @ChazzMatt, @neriamarillo, @vomer, @The Gingerbread Man and everyone that helped with this!
If you still have any questions that weren’t explained (clearly enough), feel free to ask in this thread. I will keep adding questions which I think are useful!

NEW! Gamma Corrected Brightness (GCB)
Let's do a little experiment shall we? Set your screen's brightness at 0%, 50% and 100% consecutively. Notice something odd? That's right! The 50% doesn't seem like 50%. Why you ask? Well you are not a robot, but a fabulous human that perceives brightness different (i.e:non linear). Well how do you fix this?
We are introducing Gamma Corrected Brightness! This will solve that nasty issue we talked about. Best thing yet, this baby comes with multiple modes and works for every brightness level! And this will save you battery too! With GCB you will have a greater tendency to set a lower brightness than you normally would and that saves battery life!
Four modes are:
- Stock
- Gamma 2.0 (Stubborn) – A little bit more stubborn than the natural one for those who need that
- Gamma 2.2 (Natural)– The natural one that seems normal like it should be!
- Gamma 3.0 (Nightmode) – This one is for night times ^^
How to use:
1) Download and install Furnace Kernel
2) Open terminal
3) Enter for:
Stock: echo “0” > /sys/module/lm3630_bl/parameters/gamma_correction
Stubborn: echo “1” > /sys/module/lm3630_bl/parameters/gamma_correction
Natural: echo “2” > /sys/module/lm3630_bl/parameters/gamma_correction
Nighttime: echo “3” > /sys/module/lm3630_bl/parameters/gamma_correction
4) Done!
If you love Gamma Corrected Brightness, please consider to buy @savoca and @yorici a drink!
_________________________________________________________________________________________
Profile:
Yorici_Calibrated_Punch:
Goal: Maximum brightness possible with 2.35 gamma
Result:
Average gamma: 2.36
Contrast ratio: 1:1017
Color temperature: Around 8800K
Higher saturation due to higher gamma
Maximum brightness of 500 nits vs 440 nits on stock
So brighter, more saturated and higher color temperature: what is usually called punchy!
Advanced graphs:
The color temperature might appear to be really bad, but there is a reason for this:
On full black I get these luminances: R:0,4 G:0,4 B:1,2. The color temperature of this is > 12.000K. To preserve maximum brightness I had to keep these values. This difference of 0,8 slims down when luminance gets higher. And you can see that from 25% gray and on the color temperature remains more stable.
You will also notice that gamma gets a bit more wobbly at the end. That is because the measured values change more dramatically than at the beginning of the curve. I might try to decrease the wobblyness more in the future.
See attachments for profile!
Yorici_Calibrated_Accurate
Still in the works.. (Harder to make)
_____________________________
White point:
I have taken 16 measurements of the entire RGB curve and made gifs out of them:
Luminance:
RGB levels:
Color Temperature:
The slight bumps some times are due to mistakes, vibrations (got a text), etc. Ignore them.
What can we learn from this about the white point?
The white point seems to have the most effect on red (as seen in Luminance)
Extremer white point (towards 0 and 63) tend to increase the differences between the colors
That diversion gets bigger 50% - 100% gray with white point 31 - 63
That diversion gets bigger 0% - 50% gray with white point 0 - 31
White points 0 to 10 and 53 to 63 are more unstable and lead to unpredictable results.
A white point around 31 seems the best
Anything else?

Nice thread ...

great post buddy :good:
everyone: be sure to tag me if you make new profiles and want them added to my server

There is a way to do a very basic calibration without a colourimeter... but it requires a set of digital colour cards...
Basically a sheet printed with specific squares of colour you take a picture of said card, and then compare the colour displayed on screen with the colour of the card.... With a proper calibration, the two will match. (after correcting white balance)

Tzfardaya said:
There is a way to do a very basic calibration without a colourimeter... but it requires a set of digital colour cards...
Basically a sheet printed with specific squares of colour you take a picture of said card, and then compare the colour displayed on screen with the colour of the card.... With a proper calibration, the two will match. (after correcting white balance)
Click to expand...
Click to collapse
But again dependent on your eyes, ambient lighting, etc. ;/
Not ideal, but I can't disagree that it is indeed a method.

yorici said:
But again dependent on your eyes, ambient lighting, etc. ;/
Not ideal, but I can't disagree that it is indeed a method.
Click to expand...
Click to collapse
More reliant on your eyes than ambient lighting, since you should look at the picture under the same light. but yeah, it's a very rough way... Slow, tedious, and usually used more to check the calibration and white balance/colour correct photographs than actually calibrating the screen....

Tzfardaya said:
More reliant on your eyes than ambient lighting, since you should look at the picture under the same light. but yeah, it's a very rough way... Slow, tedious, and usually used more to check the calibration and white balance/colour correct photographs than actually calibrating the screen....
Click to expand...
Click to collapse
I assume you would buy a white tile that is 6500K? I could mention it in my thread though

yorici said:
I assume you would buy a white tile that is 6500K? I could mention it in my thread though
Click to expand...
Click to collapse
Heh, the white card is based on srgb, and is what a "properly calibrated and full srgb gamut" display should show at 255/255/255, same with the black card (0/0/0).
I also have an 18% grey card...
Makes white balancing a photograph extremely simple....
But can also be used (with great difficulty) to help calibrate a display (or check the displays calibration)

My man, I am subscribed! I'll update the required posts and threads by me when I'm feeling fresher (sober) in the AM
Edit
Nice to see this got stickied nice one!
Sent from my Nexus 5 using Tapatalk

nice thread, but the link to vomer's screen profile is broken because you add (" ") between the link

The Gingerbread Man said:
My man, I am subscribed! I'll update the required posts and threads by me when I'm feeling fresher (sober) in the AM
Edit
Nice to see this got stickied nice one!
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
I'm happy with the sticky as well

gravityy said:
nice thread, but the link to vomer's screen profile is broken because you add (" ") between the link
Click to expand...
Click to collapse
Good catch

Color temp is pretty good stock. For me its the gamma that drives me nuts. I've been waiting for your results to start with mine. As you noted Franco fixed his interface.
Thanks a ton. Spent my donation/app fund this week on Peek. You're up next.

Subscribed! Awesome work and lots of good info. Thanks @yorici

Are you able to share with us your profile @yorici? Will definitely be referencing this thread when I buy my own colorimeter in the coming month!
Sent from my Nexus 5 using Tapatalk

blackt5 said:
Color temp is pretty good stock. For me its the gamma that drives me nuts. I've been waiting for your results to start with mine. As you noted Franco fixed his interface.
Thanks a ton. Spent my donation/app fund this week on Peek. You're up next.
Click to expand...
Click to collapse
Haha great dude! Yeah it's more gamma that needs some attention, but color temp can be improved too. Also, if you have the money and you are willing to spend it, I would suggest buying a xRite i1 Display Pro. You would want this one for the speed. It very quick in measuring. (I got it recommended by Francois Simond. He has been calibrating the displays of the One Plus One) If you are completely crazy about colors, you should buy a spectrophotometer. But that is > €1000...
Bobtehblob said:
Are you able to share with us your profile @yorici? Will definitely be referencing this thread when I buy my own colorimeter in the coming month!
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
I must confess Everytime I start calibrating I discover something I don't know yet and I begin investigating it further Yesterday I took 16 measurements of the white point of which I will posts gifs of (So you can see the change). I just get intrigued and stop calibrating So I have some half baked profiles I need to continue.

In my opinion n5 display looks better than any other smartphone display I came across. It's just so easy on the eyes, I get a headache when I look other oversaturated panels. I'm not a gamma expect but I know how people faces are supposed to look so I pay a lot of attention to the skin tones when I look at the images on my phone, and any custom made profile can't be compared in the terms of color accuracy to the stock one. After all, can we calibrate the screen better than Google?
Bright Red Nexus 5

Updated post 2 with gifs about the white point! Please comment if you feel I missed something or concluded wrongly
defffizz said:
In my opinion n5 display looks better than any other smartphone display I came across. It's just so easy on the eyes, I get a headache when I look other oversaturated panels. I'm not a gamma expect but I know how people faces are supposed to look so I pay a lot of attention to the skin tones when I look at the images on my phone, and any custom made profile can't be compared in the terms of color accuracy to the stock one. After all, can we calibrate the screen better than Google?
Bright Red Nexus 5
Click to expand...
Click to collapse
The 'look at the faces' is indeed a good test to see if the display is a bit oversatured. Can we calibrate better? Yes, definitely.
The reason for this is that Google didn't do the calibration LG did. And LG had to build a profile that was an good average on all displays. No display can be exactly the same and especially when you have millions of units. The calibration is therefore not optimized on a per display basis and you can improve it

@yorici,
I have a eye one pro

Database Develop

welcome