ARCHIVED: [Kernel] Picasticks OC kernel built from LG source for Optimus V

[mmarz]

Or make a backup of the keymap file you are replacing.

run_program("/system/bin/mv", "/system/usr/keylayout/thunder_keypad.kl", "/system/usr/keylayout/thunder_keypad.bak")

then continue.

 

[LeslieAnn]

I was worried about that too, the "Screenstate scaling", because of the testing I did that showed underclocking hurting performance. You can find the original script mark used here: [INITSCRIPT] screenstate_scaling - switch CPU freq governor on screen state change - xda-developers

But it was dropped from Rodimus in the later releases. I'm not sure if it is an accidental omission or it was left out on purpose because the change log does not state when it was removed. Either way, it shouldn't be an issue with the latest Rodimus.

It was probably dropped because of this:

Don't use this with SetCPU!

 

[picasticks]

Or make a backup of the keymap file you are replacing.

run_program("/system/bin/mv", "/system/usr/keylayout/thunder_keypad.kl", "/system/usr/keylayout/thunder_keypad.bak")

then continue.

OK, it turned out that busybox (in my recovery at least) had a reasonable grep, so I went halfway and put a check in so that it only restores the original file if it finds a swapped button mapping for the Menu key (that maps it to Home).

i.e. if it finds key 139 mapped to Home, it restores original. Otherwise, it does nothing.

So, please test this out and verify that it leaves your thunder_keypad.kl alone (back up first).

If your recovery shell does not have egrep, it should just do nothing.

People with reversed keymaps (i.e. remnant of some ROM with the V Xionia port with the swapped keymap hack), please try this and let me know if it reverts you back to the correct keys.

Also, this version includes the ext2-4 drivers as modules, so it's identical to 06-a. (The other 10 or so changes I tested for 07 I wound up reverting.)

picasticks-07a.zip

NOTE: There was a tiny bug in 07 (the above link is 07a) affecting users of CWMA recovery where the update script does not restore the keymap (i.e. it always leaves the keymap file alone). Big props to LeslieAnn for finding the bug and working with me to trace it. If you are the 1 other person who downloaded 07 before we fixed it, please download 07a. The kernel builds of 07 and 07a are identical.

 

[samusishere1]

I'm running the kernel on rodimus rom and it woks great but the only problem I noticed is the contrast (things that are white or bright colors) are brighter then normal. How do I fix this.?

 

[picasticks]

I'm running the kernel on rodimus rom and it woks great but the only problem I noticed is the contrast (things that are white or bright colors) are brighter then normal. How do I fix this.?

Settings / Display / Brightness?

Otherwise, there's nothing in the kernel that is tuning the display. It's using the identical LCD display driver as the one in LG's kernel. It's possible that Xionia (the kernel Rodimus uses) was using the other display driver (I can check this) and that could possibly explain a difference. What version Rodimus?

 

[samusishere1]

1.2.3

 

[jmel]

I'm running the kernel on rodimus rom and it woks great but the only problem I noticed is the contrast (things that are white or bright colors) are brighter then normal. How do I fix this.?

I am using rodimus rom and noticed the same thing.

 

[prime0025]

I am running RodimusROM 1.2.3 with picasticks-07a and everything is fine.

 

[jmel]

It might seem like it is fine, but the issue is there. It is most noticeable to me in facebook for android (not flow).

 

[picasticks]

1.2.3

OK, I downloaded Rodimus 1.2.3 and pulled the kernel config. Both kernels are using the FB_MSM_MDDI_NOVATEK_HVGA driver (which is correct; LS670 uses the HITACHI driver). So, that's not it.

Since you're coming from Xionia, my advice would be to look closer there for the bug, if there is one -- this kernel doesn't go anywhere near any of the display config and is identical to the LG kernel in that area.

Settings/Display/Brightness gives you a pretty wide range of adjustment. Always better to have to turn the brightness down than the other way around.

p.s. I looked again and that kernel is a really old build of zefie's from mid-December for the Optimus S -- it is probably not worth investigating it further. Zefie has made a ton of changes and fixes since then.

 

[samusishere1]

Well right. But its still the same when I go to that part of the setings and change brightness. but it also looks the same way when I use any xionia kernel higher then 005. I'm still new to this and a bit connfussed

 

[jmel]

OK, I downloaded Rodimus 1.2.3 and pulled the kernel config. Both kernels are using the FB_MSM_MDDI_NOVATEK_HVGA driver (which is correct; LS670 uses the HITACHI driver). So, that's not it.

Since you're coming from Xionia, my advice would be to look closer there for the bug, if there is one -- this kernel doesn't go anywhere near any of the display config and is identical to the LG kernel in that area.

Settings/Display/Brightness gives you a pretty wide range of adjustment. Always better to have to turn the brightness down than the other way around.

p.s. I looked again and that kernel is a really old build of zefie's from mid-December for the Optimus S -- it is probably not worth investigating it further. Zefie has made a ton of changes and fixes since then.

If I had to call it something, I'd say it looks like a gamma setting is 'a bit off'...

I've never noticed this with other kernels/roms. I've used rodimus, stock, and stock + xionia.

Most devs are using xionia 5 because of a number of issues that have come up with later versions. I think this is due to the other ones being ported from the optimus s, and not the v...

 

[picasticks]

Well I did go to setting and adjust that but it still looks the same. And any other kernel higher then 005 looks the same also

OK, well now you've got me a little confused as to what's going on. BTW my kernel versions and zefie's for Xionia have nothing to do with each other. His 005 is from last December, mine is from two weeks ago.

If you use Xionia higher than a certain number, he changes to the HITACHI LCD driver (Optimus S) so that might explain the problems on an Optimus V (which uses the NOVATEK driver that the S used to). I don't know when that is (it could be 006 when he updates to VC baseband for the S, it could be 013 when he mentions the LCD in his changelog) and would have to download and pull the config from every Xionia to find out. But, that could explain a problem. (Or it might not if the Hitachi driver also works on the V.)

So, are you saying that with picasticks-07, you go to the Brightness control and when you slide it with your finger the brightness doesn't change? (if so please go to Settings/About Phone and double-check the kernel version)

All I can tell you is there's nothing in my kernel that changes anything related to the graphics display. It's all the same as the kernel that came on your phone.

 

[jmel]

The brightness changes, but it looks like the gamma is set too high. Changing the brightness does not change the gamma. It seems obvious to me that there is something in the rodimus rom similar to the button swap that is being enabled/changed/whatever to make it work better with the xionia kernel. At least to me anyway...

 

[picasticks]

If I had to call it something, I'd say it looks like a gamma setting is 'a bit off'...

I've never noticed this with other kernels/roms. I've used rodimus, stock, and stock + xionia.

Most devs are using xionia 5 because of a number of issues that have come up with later versions. I think this is due to the other ones being ported from the optimus s, and not the v...

How drastic is it? Is it too contrasty (no shadow detail, brights burned out) or not enough? Is it adjustable to a reasonable level with the Brightness control?

I'm sure you aren't imagining things, all I can tell you is that it isn't the kernel. The Android/Linux kernel selects the framebuffer video driver, that's all. Something like adjusting the gamma is in userland, it's not hardcoded into a device driver. For Android that means in a .prop file or init script, it's all configurable at runtime.

Xionia 005 is the last version that works with the V9 baseband for the S ... which I assume must be the same as the V since everybody's running it here. Since then, the S had two updates, VC and VD. VC introduced a bug so it was pretty quickly followed with VD. The stock S video driver also changed (whether it was first in VC or VD I don't remember).

I would be curious what Settings / About phone says your Baseband and SW versions are, actually. i.e. mine are LS670MVD_60401001 and LS670ZVD.

p.s. another thought ... I am going to diff the actual driver code.

 

[picasticks]

OK, so I went through the actual code, for instance mddi_novatek_hvga.c. Also, check out zefie's revision history for Xionia.

The code for the V is the same as his code for 007 (and later). So, if you are coming from Xionia 005, the driver code is different. The same is true with lots of other stuff in drivers/video/msm code as well as drivers/video/backlight (the config var LCD_CLASS_DEVICE toggles lowlevel support for contrast adjustments of fb devices).

Now, this isn't necessarily "it" (one would have to build the kernel with both versions of the code and do a comparison) but I suspect it explains the issue.

Remember, if you are running Xionia 005 on your V, you are running old unofficial code which was never even intended by zefie for your phone. It might work great for you, just don't use it as a baseline.

 

[LeslieAnn]

Personally, I think it all looks more vibrant (and better) on Aphrodite with this.

 

[drezliok]

I am still on version 6. I didn't notice anything but I was using Xionia 13 before this.

 

[picasticks]

Personally, I think it all looks more vibrant (and better) on Aphrodite with this.

Well, since the code changed, it's probably more likely that someone at LG agrees with you and it was changed on purpose than that it happened accidentally.

 

[Kiernon]

Afternoon, everyone.

Just applied the .7a kernel over a fully-wiped-then-just-installed Aphrodite 2.0.1 yesterday, and I have to tell you, picasticks, this has been a total pleasure to run on.

For my personal experience (your mileage may very), here's what I've felt on my device with it:

Buttons were correctly mapped. No issues whatsoever from a fresh install.

My OC is thus far stable with a minimal heat feel from my device at a 'casual' 768/Performance scaling (the sweet spot for my particular V), and no locks, resets, or lag issues.

I use LauncherPro, and in conjunction with this ROM/kernel combo, it feels about as smooth as a device in this hardware spec could realistically get. A far cry better than stock we have when we first buy our phones.

Fresh-loaded my back-up apk's, and all work as they should on other ROMS with absolutely no strange force closings or glitching. (Everyone uses different apps, your experiences may vary - as always )

Display for me is vibrant and looks great. No weirdness that I can see, but then again I keep my display brightness fairly low, and it still looks great.

I haven't tried Bluetooth or hotspotting yet, so I can't comment on those features, but Wi-Fi and most other native phone functions I've used have worked like a champ.

It's almost like we're using software for... our... device?! What is this MADNESS?!

Still too early on battery life, but I'm doing high 90's% after 5 hours and mild texting/app useage. My auto screen turn off is set to 2 minutes, if that's relevant. It seems to be pretty good to me thus far.

Still a lot to play with, but it seems to be top notch so far.

Thanks very much for taking the time to make this, man. It's really appreciated.

-K