Jump to content

20 Jan Gr6 (V20o): MoDaCo Custom ROM for the LG Optimus 2X with Online Kitchen (stock+vanilla)


Guest PaulOBrien

Recommended Posts

Guest dbbloke

Hi Paul,

Wow, this rom is superb. GR3 had great scrolling but battery and boot time was really terrible. GR4 has a super quick boot and battery so far seems about average and will probably settle down some time.

I find the the options a little confusing where more detail like a link to some screenshots would help and trying to get a good configuration takes time cooking and flashing - fortunately have gigabit up and down internet now though :). Would be good to have a pauls reccomended google and pauls recommended LG setup (like as plus members we probably all like titanium).

Probably can wait for ICS to fix task killing. I would also love to know what other people generally install on their phones, always find out good apps from other people, because you install something then uninstall a bit later. And the whole running in background (waiting for market updates?) is just annoying.

Anyhow, thank you for your hard work. Plus membership really is worth it for the freebies alone especially now i am outside the UK again ;). Looking forward to a finished GR4 and would love to see a quadrant score of over 3000, probably need ext4?

Link to comment
Share on other sites

Guest Trym Hansen

Ah, thanks!

But then again: why do some people complain about the long boots? Do they shutdown improperly? Or is there something else going on? Somewhere that flag is set to one every time...

This had me somewhat intrigued, so I started reading a bit about the Android Property System, and started doing some tests. On the latest Topogigi, based on bits and pieces from GR3 and GR4 with a custom kernel... if you adb into that, and do a "getprop | grep dev\." you'll see that there are two properties set:

[dev.lge.ccd.cleanup] [1]

[dev.bootcomplete][1]

but on GR4 with stock kernel you get only the one:

[dev.bootcomplete][1]

So the presence of the kernel seems to facilitate the *removal* of the property, not the setting of it. Now, there are numerous ways this can happen, there could be a virtual file in /dev somewhere, which if written to the kernel will erase the property or a gazillion other ways.

I also took a look at the script, which is the init.tegra.rc script, and the comment above it says:

# rajat.suri/srinivas.mittapalli 20110602 added for SafeMode

So there can be a new Safe Boot Mode for all we know, a new key-combo during boot perhaps which will make the bootloader set it or something. Many phones have safe boot, but ours doesn't.

So I checked what happens if I just soft-reset the phone (Power+VolUp for a long time), that didn't trigger a dalvik-wipe.

Then I reset it while it was booting, and sure enough, next boot it did a dalvik-cache wipe.

So it actually seems to be a persistent property which has to be removed, not set. (You're not supposed to be able to remove a property once it's there. You can change its value, but not erase it.)

So I think it's easy to connect the dots: There are two properties starting with "dev." One of them acts as the flag [dev.bootcomplete], and the other one as a trigger, removed only when the flag has been set to 1. And it's persistent. Unless removed by some mechanism obviously depending on the new stock kernel, or the kernel itself, it'll stay.

I think it's also safe to assume these properties and mechanisms will be removed from a final release, or they wouldn't be named "dev.something":

I also downloaded the source to the Su660 GB kernel to see if I could find any mention of the property there, no luck.

So there you have it, that's all I know.

Edited by Trym Hansen
Link to comment
Share on other sites

Guest SuperSkill

When doing CWM i get this: "No sd-ext found. Skipping backup of sd-ext."

How problematic is it ? (what are the implications of not backing up the sd-ext?)

P.s I use pauls CWM and it backsup to my SD card ( I am sure this is the problem ).

Any Ideas ?

Its normal because you have an internal sd which is partitioned, you get your nessesary backup, the external sd will not be affected if wiping and installing.

SuperSkill

Link to comment
Share on other sites

Guest AngelOfMors

Gingerbread theme:

GPS conection - switches between the two icons (first icon from stock theme, second icon from gingerbread theme), and must be aim and it blinking circle

Link to comment
Share on other sites

Guest c.joenie

This had me somewhat intrigued, so I started reading a bit about the Android Property System, and started doing some tests. On the latest Topogigi, based on bits and pieces from GR3 and GR4 with a custom kernel... if you adb into that, and do a "getprop | grep dev\." you'll see that there are two properties set:

[dev.lge.ccd.cleanup] [1]

[dev.bootcomplete][1]

but on GR4 with stock kernel you get only the one:

[dev.bootcomplete][1]

So the presence of the kernel seems to facilitate the *removal* of the property, not the setting of it. Now, there are numerous ways this can happen, there could be a virtual file in /dev somewhere, which if written to the kernel will erase the property or a gazillion other ways.

I also took a look at the script, which is the init.tegra.rc script, and the comment above it says:

# rajat.suri/srinivas.mittapalli 20110602 added for SafeMode

So there can be a new Safe Boot Mode for all we know, a new key-combo during boot perhaps which will make the bootloader set it or something. Many phones have safe boot, but ours doesn't.

So I checked what happens if I just soft-reset the phone (Power+VolUp for a long time), that didn't trigger a dalvik-wipe.

Then I reset it while it was booting, and sure enough, next boot it did a dalvik-cache wipe.

So it actually seems to be a persistent property which has to be removed, not set. (You're not supposed to be able to remove a property once it's there. You can change its value, but not erase it.)

So I think it's easy to connect the dots: There are two properties starting with "dev." One of them acts as the flag [dev.bootcomplete], and the other one as a trigger, removed only when the flag has been set to 1. And it's persistent. Unless removed by some mechanism obviously depending on the new stock kernel, or the kernel itself, it'll stay.

I think it's also safe to assume these properties and mechanisms will be removed from a final release, or they wouldn't be named "dev.something":

I also downloaded the source to the Su660 GB kernel to see if I could find any mention of the property there, no luck.

So there you have it, that's all I know.

Hey Trim,

thanks a lot for your response :), you actually made me a little more wanting to do a deepdive myself on the property part :). I still wonder why it is set for our normal boot. Let's see what happens if Paul comments the code away. (Because having actual proper Dalvik cache and all should improve performance ... yet the wipe of the cache can still point to the risk of something failing, so we should test :D!)

Link to comment
Share on other sites

Guest ODIN679

Hey Paul!!

Just one thing, when I play Trial Extreme 2 HD, the first time goes great, the I quit wait for a bit, use the phone, and start the game again and it does not pass the first screen...

Installed neoblaze kernel and that problem solved it self!

Any one else noticed this??

Link to comment
Share on other sites

Guest gizzy98

Ok so i installed the latest BB and got a a success message.

Then I flashed this via the kitchen straight away.

It boots but gives me several force close errors and wont let me into the 'about phone' under settings.

Also when I go to power off it just says its shutting down then comes back at an unresponsive homescreen. reboot to recovery via adb just reboots the phone and doesnt take me to recovery so im going to have to figure out how to reflash now :)

EDIT

Ok well I just ran through the BB reflash again. Successful and still didnt wipe my phone but the phone boots and no force closes. May need to manually re push CWM though as I still cant boot into it directly via adb.

Edited by gizzy98
Link to comment
Share on other sites

Guest stonehz

After installing GR4, I noticed 2 things:

1) During the 1st boot , the wizard starts and then the PIN unlock (if your sim is pin protected).

Once you entered the pin and press ENTER ,the system restarts.. (Not a biggie :) )

2) I unticked the "RemoteCall" in the kitchen but it was installed anyway. Kitchens options provided.

options.txt

Link to comment
Share on other sites

Guest Topogigi

.....Long post about long boot issue......

Hi, TrymHansen, nice to meet you here. Your posts are always intriguing, and it is a real pleasure to read them. But this time you missed a point: if one property is a flag and the other is a trigger, why my rom boots fast (from v. 1.6) even with custom kernels when the flag and the trigger are both set to 1? Shouldn't it wipe the cache at every boot if the flag is set to 1? A simple file compare between the two ramdisks will reveal the key. :-)

But this is trivial, and Paul can for sure solve this and other issues with ease. But I' am currently facing other issues with custom kernels and GB leaks > V20b, and I need Paul's and your thoughts about it.

Starting from the v20e leak, LG changed something in its GB kernel about the way emmc (SD cards) are mounted for safety reasons. I solved that issue taking the vold.fstab from the v20b release and putting it in place of the original one. So, SD cards are still mounted, but this is only a workaround. The reason why LG changed the way SD cards are mounted is now clear to me: if you reboot the phone without a complete poweroff cycle, there are chances that the SD card will be recognized as damaged at next reboot and not mounted at all. This leads to an unstable condition in which the SD card begins to overheat and this is not safe for our phones. I could experiment this issue from time to time and not on a regular basis, so your mileage can vary depending on how many files and dirs are stored on your SD card. If you turn off the phone and then turn it on, it is always safe as the card is always mounted as it should. This leads me to believe that LG changed the way SD cards are mounted for a precise reason, and that the workaround I found is not on the safe side.

But there is another problem I noticed starting from v20i/GR3 that now is reproduced on v20j/GR4: USB tethering is broken (worked flawlessly with v20e), and TrymHansen itself gave me an alert on a new weird USB behaviour. When the phone is connected to a PC, and you hit home, the USB icon in the notification bar vanishes and you're unable to properly disconnect the phone without pulling the cable. So I logged a session with adb and discovered that a USB compatibility mode is invoked because the kernel couldn't provide the proper USB switching mode.

These and other little things persuaded me that LG has changed something in the depth of the kernel drivers (at least for emmc and USB), and that we could not have a fully functional GB leak with custom kernels anymore, at least until new kernel sources will come to light.

I think that Paul is the only and the one who can throw a bit of light on that, and I hope he will find the way to solve these issues.

Otherways, we have to stay with the original unmodified kernel (besides init.d support), until the official release (and the new kernel sources) will be published.

CU soon.

Edited by Topogigi
Link to comment
Share on other sites

Guest Trym Hansen

Hi, TrymHansen, nice to meet you here.

Hiya Topo, nice to see you here as well.

Your posts are always intriguing, and it is a real pleasure to read them. But this time you missed a point: if one property is a flag and the other is a trigger, why my rom boots fast (from v. 1.6) even with custom kernels when the flag and the trigger are both set to 1?

Oh, I'm sure I've missed quite a lot, this was in no way any extensive research. First let me clarify the the post wasn't about solving the long boot issue, we already know how to do that, but it was a look into the property system.

You *know* why topogigi roms boot fast, you've commented out the "on property:dev.lge.ccd.cleanup=1" line. (If you didn't do it, someone else did. I just checked the init.tegra.rc in both 1.9 and 2.0.)

Shouldn't it wipe the cache at every boot if the flag is set to 1? A simple file compare between the two ramdisks will reveal the key. :-)

I assume you're talking about the above, the commenting out of the line which checks the property.

As for the rest of your questions I leave them in the capable hands of Paul, way out of my area of, well, I nearly said "expertise", but will instead say "informed guesses."

Edited by Trym Hansen
Link to comment
Share on other sites

Guest Brock Sampson

So far GR4 is just great---battery life, speed, stability, etc. Thanks for all the hard work, Paul; this phone would truly suck if it was still stuck with the stock LG Froyo release that it came with.

I did notice one tiny bug, but it may be because I was too lazy to perform a wipe moving from GR3. Toggle 2G Settings crashes with:

E/AndroidRuntime(19114): android.content.ActivityNotFoundException: Unable to find explicit activity class {com.mb.toggle2g/com.mb.toggle2g.Toggle2G}; have you declared this activity in your AndroidManifest.xml?

And I noticed that I can no longer bypass the unlock screen with the menu key. Can this feature be included as an option in the kitchen? I find it incredibly annoying to have to click a button and then swipe to unlock the phone, but others apparently have the opposite view.

Link to comment
Share on other sites

Guest Topogigi

Hiya Topo, nice to see you here as well.

Oh, I'm sure I've missed quite a lot, this was in no way any extensive research. First let me clarify the the post wasn't about solving the long boot issue, we already know how to do that, but it was a look into the property system.

That was the intriguing part. I already knew the way to make it boot fast starting from v.1.6, but I never checked the properties on runtime and seeing that the property was set in any case, did surprised me. There's evidence that something has changed somewhere.....but who's setting it to 1? Custom kernels don't for sure.

You *know* why topogigi roms boot fast, you've commented out the "on property:dev.lge.ccd.cleanup=1" line. (If you didn't do it, someone else did. I just checked the init.tegra.rc in both 1.9 and 2.0.)

Yes, that was the trivial part of the problem....

As for the rest of your questions I leave them in the capable hands of Paul, way out of my area of, well, I nearly said "expertise", but will instead say "informed guesses."

We're sharing the same area.

Edited by Topogigi
Link to comment
Share on other sites

Morning all, hope everyone had a good weekend! :D

Updates planned for today include...

  • Update custom kernel images to fix dalvik-cache issue
  • Patch MCK for touchscreen sensitivity
  • Post MCK git link
  • Add Neoblaze kernel to the kitchen
  • Check Toggle2G issue reported above
  • Check RemoteCall inclusion reported above
  • Check GPS icon issue on GB theme reported above
  • Check stock gingerbread keyboard functionality (may swap to Steven Lin version to restore vibrate functionality).
  • Update prebakes
  • Add a couple more select items to the kitchen
  • Prepare post for full Gr4 release :D

Just a reminder that the 'MoDaCo Ad-Free and kitchen access for $9' promotion is still on - details, your support is very much appreciated! :)

With regards to the 'kernel oddities', there's a lot we really can't do much about until such time as LG release their new kernel source. If you want *rock solid*, you should probably stick with the stock kernel. I am looking into building EXT4 modules etc. that work against the stock kernel tho, which would be nice.

P

Link to comment
Share on other sites

Guest Topogigi

.........

With regards to the 'kernel oddities', there's a lot we really can't do much about until such time as LG release their new kernel source. If you want *rock solid*, you should probably stick with the stock kernel. I am looking into building EXT4 modules etc. that work against the stock kernel tho, which would be nice.

P

This sounds really good. Did not think about it before. If you build cifs, tun and other goodies as modules, there will be no reason to stick with custom kernels besides the OC/UV thingy. Great idea indeed.

Cheers.

Link to comment
Share on other sites

Guest c.joenie

Would those modules then be portable to other kernels? E.g. other devices/kernel configurations? This would allow a lot of custom rom developers to speed up the process when there's no full source to built from :).

Link to comment
Share on other sites

Guest Topogigi

Would those modules then be portable to other kernels? E.g. other devices/kernel configurations? This would allow a lot of custom rom developers to speed up the process when there's no full source to built from :).

Generally speaking they should not be portable to other kernels/configs. I think Paul will extract the current .config from the stock kernel and build the modules against the source we have using the same .config file, only building further options as external modules. If this will be the way, some modules will work and some other not (dependencies are a mess with linux kernels). But hopefully the relevant modules will work and that will be really a great step beyond.

Link to comment
Share on other sites

Hi.

In the gingerbread theme, after a phone call, the statusbar changes from flat black, to having a gradient.

I think this is the culprit :

framework-res.apk -> res -> drawable-hdpi -> statusbar_background.9.png

(It has the gradient)

Can we swap this for a flat black png ?

Cheers

Link to comment
Share on other sites

Hi.

In the gingerbread theme, after a phone call, the statusbar changes from flat black, to having a gradient.

I think this is the culprit :

framework-res.apk -> res -> drawable-hdpi -> statusbar_background.9.png

(It has the gradient)

Can we swap this for a flat black png ?

Cheers

Noted, i'll fix that.

P

Link to comment
Share on other sites

Changelog

17 Oct 13:35

  • Updated MoDaCo Custom Kernel to r24 - ramdisk fix for slow boot (dalvik-cache rebuild) and incorporating touchscreen sensitivity fixes from pastime1971 / Neoblaze

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.