ARCHIVED: [DEAD ROM]The Scott Pilgrim ROM (CM7 Gingerbread, Zefie Edition)

Status
Not open for further replies.
this CWMA thing is driving me insane I changed all the code that would say "expects 2 args" and yet it still says it how am I missing this. I even flashed the recovery.img that cyanogen created. grep is not finding a hidden copy in the source, so I have no idea what I am doing wrong. Grrr.

edit i think i just found it lol, i hope

Edit2: apparently the fail is within updater-binary within the zip. So hopefully Cyanogen fixed this and generates a proper updater-binary to go with their new updater-script :)
 
Last edited:
im am chewing up batteries and I need a good app to help. Wherer I work I go into roaming all day long. With thunderrom I used juice defender and got much bettery life. But it will nto work with gingerbread. anyone have a saver that works?
 
im am chewing up batteries and I need a good app to help. Wherer I work I go into roaming all day long. With thunderrom I used juice defender and got much bettery life. But it will nto work with gingerbread. anyone have a saver that works?

On his site you can sign up for his beta which supports gb

Sent from my LS670 using Tapatalk
 
im am chewing up batteries and I need a good app to help. Wherer I work I go into roaming all day long. With thunderrom I used juice defender and got much bettery life. But it will nto work with gingerbread. anyone have a saver that works?

unfortunately we do not have access to change the roaming mode on cm7 since lge does it in a sneaky proprietary way. I'd suggest going back to ThundeROM.
 
with Xionia v013 fixing all the blank screen issues it is time to build another NIGHTLY with v013 and hope the flashing issue is fixed.

Naturally building takes hours, so enjoy Xionia v013 and CWMA .6 while I enjoy some Xbox 360. lol
 
with Xionia v013 fixing all the blank screen issues it is time to build another NIGHTLY with v013 and hope the flashing issue is fixed.

Naturally building takes hours, so enjoy Xionia v013 and CWMA .6 while I enjoy some Xbox 360. lol

Will the buildprop proximity fix from 2-3 pages back be included in the new nightly?

And thanks for continuing to work on this, especially since you seemed like you were leaving this rom forever a couple days ago.
 
Will the buildprop proximity fix from 2-3 pages back be included in the new nightly?

And thanks for continuing to work on this, especially since you seemed like you were leaving this rom forever a couple days ago.

buildprop proximity fix is placebo and I'll tell you why.

ro.* props are only read in the android framework not in the kernel, so an ro.lge property would need something in the android code (probably from LG) to read and apply said property.

While not impossible, I highly doubt (with 99% certainty) that there is no such code in Cyanogen.
 
buildprop proximity fix is placebo and I'll tell you why.

ro.* props are only read in the android framework not in the kernel, so an ro.lge property would need something in the android code (probably from LG) to read and apply said property.

While not impossible, I highly doubt (with 99% certainty) that there is no such code in Cyanogen.

So, in other words, on any AOSP ROM for this phone (well... in the hypothetical situation that more than one exists ;) ), all ro.lge values related to kernel functionality in the build.prop are void?
 
have the new lcd drives in my phone. at first i installed the cm7 and got black screen. i reinstalled then unzipped the v.o13 kernell before i rebooted. it did fix the problem just to let everyone know for future references. it works great.
 
So, in other words, on any AOSP ROM for this phone (well... in the hypothetical situation that more than one exists ;) ), all ro.lge values related to kernel functionality in the build.prop are void?

yeah coz its not really a kernel parameter it is an android parameter

even if it was a kernel parameter there would still need to be code in the framework to read the prop value and assign it to the kernel parameter.

If you are looking for kernel parameters look around in /proc maybe we can just write a number to a proc value and fix it? xD
 
yeah coz its not really a kernel parameter it is an android parameter

even if it was a kernel parameter there would still need to be code in the framework to read the prop value and assign it to the kernel parameter.

If you are looking for kernel parameters look around in /proc maybe we can just write a number to a proc value and fix it? xD

Gotcha - my limited knowledge and I assumed that the framework would be more carrier-neutral and all that jazz :P

However, I'm going to use my just-enough-to-be-dangerous abilities to search through said /proc directory and see what I can do... If the world implodes... My b.
 
Perhaps I'm going about this the wrong way.

When I try to "adb pull /proc", I get the output "Skipping special file" for each file, both while running Android or recovery. Couldn't find anything about this on Google - any ideas?

Also, the grep application in the market force closes every time it tries to go through /proc :P
 
Perhaps I'm going about this the wrong way.

When I try to "adb pull /proc", I get the output "Skipping special file" for each file, both while running Android or recovery. Couldn't find anything about this on Google - any ideas?

Also, the grep application in the market force closes every time it tries to go through /proc :P

Not how it works ;)
The /proc filesystem
 
buildprop proximity fix is placebo and I'll tell you why.

ro.* props are only read in the android framework not in the kernel, so an ro.lge property would need something in the android code (probably from LG) to read and apply said property.

While not impossible, I highly doubt (with 99% certainty) that there is no such code in Cyanogen.

No way. I'm sorry, but my phone prox sensor only worked 1 in 10 times before I switched it to 25, and now it works 20 times in 20!

This is what I thought to myself as I read your post at least.

Determined to prove you wrong, thrilled that the fix actually did work, I went ahead and restored my build.prop backup and rebooted, then called my voicemail, sure that the screen wouldn't work right anymore.

It worked. Flawlessly. You were right Zefie. I swear my prox sensor was total **** before and worked flawlessly after the fix, but now that I "reverted" the fix, it still works flawlessly. You win this round my friend! Either it really is placebo, or somehow changing that setting scared my phone straight, but either way it works now at 100 as well...
 
Well, I did a "sysctl -a" and looked up each feasible value that wasn't network related... I'm not seeing anything sensor-related. But now I understand development frustration... Since I've spent an entire 30 minutes on this ;)
 
  • Like
Reactions: zefie
buildprop proximity fix is placebo and I'll tell you why.

ro.* props are only read in the android framework not in the kernel, so an ro.lge property would need something in the android code (probably from LG) to read and apply said property.

While not impossible, I highly doubt (with 99% certainty) that there is no such code in Cyanogen.

Well, it worked for me and few other people, so maybe its just changing the file that does the trick. Also, if nothing is calling that property, could that be the cause of all our proximity problems?
 
Status
Not open for further replies.

Forum statistics

Threads
957,474
Messages
6,973,214
Members
3,163,826
Latest member
eatmynuts