[R&D][MOD]Nexus S Color Correction - Nexus S Android Development

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.

Related

Excel VB question: re: Arrays

Hey,
I am working on something for work and it has to do with a simple database (excel file) with data kept in rows. This data is accessed using a userform that looks up a query that happens to be the data kept in the first column of the spreadsheet. Basically, each row contains 46 cells, including the first cell (the query).
I am hoping to use the same userform to search, update, save, print and quit excel. So far search works:
Code:
Sub CommandButton1_Click()
dim query as range
set query = range("A:A")
call readData(query.find(TextBox1, lookat:=xlWhole).row)
End Sub
Private Sub readData(x as integer)
Dim boxes as range
set boxes = range("A:A")
TextBox1 = boxes.cells(x).offset(0,0)
TextBox2 = boxes.cells(x).offset(0,1)
....
End Sub
This works fine for search; however, as there is 45 boxes containing different kinds of data, I would rather read the cells from the spreadsheet using a loop and setting the TextBoxN as a static array:
Code:
Sub readData(x as integer)
***** VB treats array(45) as an array having 46 elements *****
dim textBoxArray(45) as [u]Variant[/u]
set textBoxArray = array(TextBox1, TextBox2... TextBox46)
For i = 1 to 46
textBoxArray(i-1) = cells(x, i)
Next i
End Sub
Note that "query.find(TextBox1, lookat:=xlWhole).row" returns the row number of the query and this is passed as an integer to the readData sub-routine and is referred to as "x".
I would like to do this for the read and then do the same, although opposite for the update (i guess I could call it the 'write' back to the excel worksheet).
The problem is, with this code I get an error that says the array is not declared or arranged (Japanese laptop: 配列は割り当てられません。)
Question 1
Any of you developers with any vb experience know how I can correctly declare my array (would be nice if I could decare the array globally so that I don't have to re-declare it for every sub-routine, and I can just use the for loop in each sub-routine)?
At present, all the code is within the userform and I cannot seem to declare outside of a subroutine:
Code:
Public boxArray(45) as Variant
Sub CommandButton_Click()
...
End Sub
Question 2 SOLVED I removed the "set" from the line where I filled the array with each textbox. Tested it again and all data is flowing correctly. Only need question 1 answered.
Thank you.
Hey all, thanks for the replies; I didn't think the thread would be this popular.
I solved the problem with global variables. Instead of setting a fixed array size in the main code section dec area, I found another way of assigning values to all 46 textboxes.
Instead of:
Code:
Dim boxArray(45) as Variant
boxArray(45) = array(TextBox1, TextBox2, ... TextBox46)
then
Code:
For i = 1 to 46
boxArray(i-1) = cells(x,i)
Next i
I used vb's Control method/function (no array necessary):
Code:
For i = 1 to 46
Control("TextBox" + CStr(i)) = cells(x,i)
Next i
So i turned 46+ lines into 6+ lines into 3 lines.
MODS, this thread may be closed. THanks.

[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.

[DEV/APP] Resolution changer for HDMI Landscape Mirroring on Blur System

This application will allow you to change the resolution of the mirroring mode.
To use it, you'll have to re-sign it with the same signature as the system, if you successfuly installed the mirroring mode you'll find a way since the problem is the same.
You'll also need to change the package MirrorService.apk because I changed an option in it to allow the use of the function that will change the resolution for all kind of android builds (eng, user, userdebug).
Topic about the HDMI Landscape Mirroring mod : http://forum.xda-developers.com/showthread.php?t=1348692
It's a really simple software, it just requires to activate the mirroring mod to be able to change the resolution, you'll keep it to until the next change or reboot.
Language : English/French
Download v1.0.2 : https://rapidshare.com/files/225894882/MirrorResolution.apk
MirrorService.apk from Photon modded : https://rapidshare.com/files/426697782/MirrorService.apk
Source : https://rapidshare.com/files/2349891096/MirrorResolution_source.zip
To achieve this I used the hdmi user library from the motorola addon pack for atrix.
Pack available here : http://developer.motorola.com/docstools/tools/
Docs : http://developer.motorola.com/docstools/library/motorola-hdmi-dual-screen-api/
I reverse-engineered the mirroring service to create an user library to use with Eclipse.
Source & lib : https://rapidshare.com/files/3144458217/mirror_lib.zip
Awesome job, mate!
Very cool.
Works good on NottachTrix. OK to add to the next release?
One question, are the resolutions labeled correctly in the chooser? When I choose 1920 x 1080 60hz it defaults to 800 x 600. But when I choose 1920 x 1080 50hz it applies 1920 x 1080 60z. I know my monitor doesn't do 1920 x 1080 50hz so something seems weird.
I installed the app and replaced the mirrorservice.apk but your mirrorservice file broke my mirror :S
I tested only with the app itself and it changed the resolution, but it just displayed an static image of the app and never changed.
Also, when selecting 1080p, stayed in 720p, but selected 1280x1024 and changed to 1080p.
How can I fix the mirrorservice.apk? What did you change ? maybe I can edit my apk
sotodefonk said:
I installed the app and replaced the mirrorservice.apk but your mirrorservice file broke my mirror :S
I tested only with the app itself and it changed the resolution, but it just displayed an static image of the app and never changed.
Also, when selecting 1080p, stayed in 720p, but selected 1280x1024 and changed to 1080p.
How can I fix the mirrorservice.apk? What did you change ? maybe I can edit my apk
Click to expand...
Click to collapse
The signature of MirrorService.apk needs to match your systems sig or else it won't work properly.
I first installed his resolution app and tried it out with my regular mirrorservice and it didn't work.
Since my rom is already totally resigned I just resigned his mirrorservice.apk and pushed it and then it worked properly. (except for the res labels)
depending on what rom youre using you can try resigning his mirrorservice and pushing it to see if that helps. it should work if youre using one of my roms, not sure about cm7 roms though.
Nottach said:
The signature of MirrorService.apk needs to match your systems sig or else it won't work properly.
I first installed his resolution app and tried it out with my regular mirrorservice and it didn't work.
Since my rom is already totally resigned I just resigned his mirrorservice.apk and pushed it and then it worked properly. (except for the res labels)
depending on what rom youre using you can try resigning his mirrorservice and pushing it to see if that helps. it should work if youre using one of my roms, not sure about cm7 roms though.
Click to expand...
Click to collapse
Actually, pushed back the original mirrorservice, and it kind of works, but like you said, the resolutions are not correclty labeled... 1024x768 is 1080p on mine, but it works after a restart
how to resign?
I decided to install signapktic to resign the app, but had a couple of questions. You say to sign using signature of my system. That is not the testkey, correct? So how would I obtain the signature of my system? Also, do I sign both apps or just the mirrorresolution.apk?
I also feel like I'm completely missing the point of signatures on apks, but I'll figure it out in due time.
Just to confirm, does this work on CM7 ROM's, or is it only for Blur?
For the list of resolutions, I get it of your extern monitor and based on the motorola doc.
Code:
static final int HDMI_STANDARD_INVALID = -1;
static final int HDMI_STANDARD_AUTO = 0;
static final int HDMI_STANDARD_2_3_60HZ = 1; // 720x480P @ 60Hz
static final int HDMI_STANDARD_4_60HZ = 2; // 1280x720P @ 60Hz
static final int HDMI_STANDARD_17_18_50HZ = 3; // 720x576P @ 50Hz
static final int HDMI_STANDARD_19_50HZ = 4; // 1280x720P @ 50Hz
static final int HDMI_STANDARD_1_60HZ = 5; // 640x480P @ 60Hz
static final int HDMI_STANDARD_16_60HZ = 6; // 1920x1080P @ 60Hz
static final int HDMI_STANDARD_31_50HZ = 7; // 1920x1080P @ 50Hz
static final int HDMI_STANDARD_PC_SVGA_60HZ = 8; // 800x600 @ 60Hz
static final int HDMI_STANDARD_PC_XGA_60HZ = 9; // 1024x768 @ 60Hz
static final int HDMI_STANDARD_PC_SXGA_60HZ = 10; // 1280x1024 @ 60Hz
static final int HDMI_STANDARD_PC_WXGA_60HZ = 11; // 1440x900 @ 60Hz
static final int HDMI_STANDARD_PC_WSXGA_60HZ = 12; // 1680x1050 @ 60Hz
static final int HDMI_STANDARD_PC_LD_60HZ = 13; // 1366x768 @ 60Hz
On my LG tv all res are ok.
And no problem to use it on all roms you want, i shared it for that
Pretty cool will give it a try and see if i can go hd thanks
Is this compatible with cm9 or cm7 or only blur based roms?
Sent from my cm9 kang atrix son
Notorious544d said:
Just to confirm, does this work on CM7 ROM's, or is it only for Blur?
Click to expand...
Click to collapse
I don't see an apk with that name in system/app on my CM7, so I assume it's for Blur.
Sent from my MB860 using Tapatalk
how do i fing the correct signature to sign the apk with? im about to do so now but im slightly confused as to how to locate said signature
Sadly, it doesn't work on cm9 turl v8. It says searching for tv, while my tv displays atrix screen. Why it doesn't find it? Anyone else having this problem?
It's build to work with motorola dual screen api sry ...
djeman said:
It's build to work with motorola dual screen api sry ...
Click to expand...
Click to collapse
What do you mean by that? People confirmed that this worked fine on their TVs. Anyone else having troubles on CM9?
Thanks for making the app. I'm just curious on the purpose of the app. What's the advantage of manually modifing the HDMI resolution? Currently, when I plug the Atrix to my HDTV, it always defaults to the maximum screen resolution of the connected display. In my case, it's always 1920x1080 60Hz. To my understanding, your app allows me to modify to lower screen resolution. However, is there any advantage on doing this?
djeman said:
This application will allow you to change the resolution of the mirroring mode.
To use it, you'll have to re-sign it with the same signature as the system, if you successfuly installed the mirroring mode you'll find a way since the problem is the same.
You'll also need to change the package MirrorService.apk because I changed an option in it to allow the use of the function that will change the resolution for all kind of android builds (eng, user, userdebug).
Topic about the HDMI Landscape Mirroring mod : http://forum.xda-developers.com/showthread.php?t=1348692
It's a really simple software, it just requires to activate the mirroring mod to be able to change the resolution, you'll keep it to until the next change or reboot.
Language : English/French
Download v1.0.2 : https://rapidshare.com/files/225894882/MirrorResolution.apk
MirrorService.apk from Photon modded : https://rapidshare.com/files/426697782/MirrorService.apk
Source : https://rapidshare.com/files/2349891096/MirrorResolution_source.zip
To achieve this I used the hdmi user library from the motorola addon pack for atrix.
Pack available here : http://developer.motorola.com/docstools/tools/
Docs : http://developer.motorola.com/docstools/library/motorola-hdmi-dual-screen-api/
I reverse-engineered the mirroring service to create an user library to use with Eclipse.
Source & lib : https://rapidshare.com/files/3144458217/mirror_lib.zip
Click to expand...
Click to collapse
Hi Djeman,
That can be awsome if you can work on it for CM7 based ROM, I'm on Neutrino and this is the last thing I'd like to get !
Thank you in advance.
Nipit said:
What do you mean by that? People confirmed that this worked fine on their TVs. Anyone else having troubles on CM9?
Click to expand...
Click to collapse
i don't see any post with cyoagen mod roms claimed to be working with this. wish it was....
Unfortunately it doesn't work on my Droid 3 5.7.894, am I doing something wrong? After replacing MirrorService.apk there is no HDMI mirroring anymore and the app says not mirroring... Help is highly appreciated.
THANKS

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

Tasker Scene WebView JavaScript Interaction

Is it possible to call a Javascript function that exists within a WebView from Tasker? I tried calling a URL on the WebView of "javascript:FUNCTION_NAME()", but that did not seem to work.
This is a completely random example. Lets say, from Tasker, that I want to be able to change the background color of the body of the WebView.
In the webview, I have the code
JavaScript:
function ChangeBGColor(NewColor)
{
document.body.style.backgroundColor=NewColor;
}
I want to be able to call ChangeBGColor() from Tasker with a color.
I remember having this same question a while back and was unable to find a solution that didn't involve sending HTTP requests, so I came up with a really weird hacky solution. I'm not sure its going to work for your situation, but maybe it can give you some ideas.
On the web side- have a transparent div element that occupies a single pixel. Put it in a corner or somewhere you won't accidently touch it. Now, add an event listener to it like this:
element.addEventListener('touchend', (e)=> {
let x = e.changedTouches[0].clientX;
let y = e.changedTouches[0].clientY;
renderColor(x, y);
});
On the Tasker side- If you don't already have it, download AutoInput, which is plugin that was created by Joao Diaz before he took over development of Tasker, and its incredibly cheap for what it does. You can use it to simulate a swipe gesture that starts at that exact spot on the screen, and ends at the coordinates you specify. You now have a way to send two values from tasker to you Javascript with a possible range of your screen resolution.
This might be challenging if you want the full spectrum of colors, because ideally you would want 3 parameters with 256 possibe values (0 for 00 and 256 for FF), so you'll have to figure out a way to encode and decode your color. You could either dumb down the resolution of colors and then use some math involving the modulus operator, but a better way would be to send the data via two swipe gestures, which would give you 4 parameters to work with- so to send white with full opacity (FFFFFFFF), simulate a swipe starting at 0,0 and ending at 256, 256 (FF or 256 for your alpha value, and the same for red), have your Javascript function store that in a variable. Then, send the second swipe which in this case will be the same as the first, and you now have 4 values to give you your color. Keep in mind you'll want to offset everything by 1 or you wouldn't be able to send black, since swiping from 0,0 to 0,0 won't trigger anything.

Categories

Resources