[ROM] CM6-clean for development / testing

[Guest hzf]

Did you flash the installable zip I uploaded after you had an installed rom, or did you add it to the rom before installing?

I'm trying to establish what is happening with some strange patterns I've been seeing when installing modifications of these two roms.

I flashed it over the existing rom, but i can check next week the other option.

[Guest dr.flo]

What is the current status of GPS icon bug, especially on CM 6.1.1 where no workaround is in framework... Is anybody using the replacement libloc_api and is happy with it?

We should decide which is the best combination. I would then either update CM 6.1.1 with GPS icon workaround as in CM 6.2 - or alternatively use new libloc_api in both roms and remove workaround in CM 6.2

i dont know it is bug or not same as the others CM6 Mod

when video playing, it cant stop/close (using back/ home) button,

We should waiting until the video end.

This issue will go away when replacing Gallery with QuickPic as it is the case in TXG...

@twrock: I will try your latest OC boot image (on 6.2) for a while and then report if I notice any issues...

[Guest twrock]

What is the current status of GPS icon bug, especially on CM 6.1.1 where no workaround is in framework... Is anybody using the replacement libloc_api and is happy with it?

We should decide which is the best combination. I would then either update CM 6.1.1 with GPS icon workaround as in CM 6.2 - or alternatively use new libloc_api in both roms and remove workaround in CM 6.2

This issue will go away when replacing Gallery with QuickPic as it is the case in TXG...

@twrock: I will try your latest OC boot image (on 6.2) for a while and then report if I notice any issues...

I tested the GPS fix (libloc_api.so) in 6.1.1 and found it worked flawlessly to resolve the GPS icon bug.

But then just a half hour ago I found that I can not get any sensor based screen rotation to work. I'm working on trying to figure out if this was a problem from the beginning or something I introduced later myself. I so rarely use screen rotation that I can't remember if it ever worked. I'll let you know what I find.

Regarding Gallery3D, complete bloatware. QuickPic is the perfect lean alternative for our slower machines.

Edit1: Virgin install of cm6-u8220-20120206-v2.zip, sensor based screen rotation does not work. On a positive note, I think that at least means that the rotation problem has nothing to do with libloc_api.so.

Dr.flo, did you make any other changes from v1 to v2 that might have introduced a rotation problem? I honestly can't say whether v1 had rotation or not. I so rarely use it.

Edit2: Virgin install of cm6-u8220-20120202-v2.zip verified that rotation works perfectly there.

Edited February 23, 2012 by twrock

[Guest dr.flo]

Dr.flo, did you make any other changes from v1 to v2 that might have introduced a rotation problem? I honestly can't say whether v1 had rotation or not. I so rarely use it.

Edit2: Virgin install of cm6-u8220-20120202-v2.zip verified that rotation works perfectly there.

I didn't do anything I'm aware of. Also, the u8220 device folder (where the source for sensors lib is) is the same for 6.2 and 6.1.1 builds. It should be the same for both builds and for all -vX variants of them. I have no clue at the moment...

[Guest desalesouche]

I still have not been able to test this. But I still intend to do so.

I also want to test the DSP Manager in this rom to see what help that might be.

Regarding the loudspeaker, currently I do not have the volume all of the way up for that. If I turn it all the way up, it becomes distorted. I fear that an even louder volume will damage the speaker. What I want to achieve is louder phone call speaker and louder headphone volume when playing music.

hi.after some in-vivo test in the subway...i can tell for rom um840-20120213 without change = can't hear a lot when watching movie/listening music...

rom um840-20120213 + libasound.so = clear and nice louder sound /can listen understand easily movie/music while subway on the way and people around talk etc...

the other file *csv for me seem to be ineficient =no signicative improvent/change ...going to test same way with cm6.1/cm6.2/cm7.2

ps:will test your zip with cm6 and tell you... for me batterylife is a nightmare...so i have 2 but may be i shouldn'toc to 729....:)

edit: i did test cm6.2 with your zip...i have only one issue but majore(don't know for the others) i am asked every 5 sec about to reenter my code....so :blink: have to stop with ...:unsure:

Edited February 23, 2012 by desalesouche

[Guest pier11]

libasound.so ?

what is this?

[Guest desalesouche]

;)

libasound.so ?

what is this?

it is a file that i took from an apk...it might also work on cm6.1/cm6.2/and cm7.2(i am actually testing)

the apk is AudioBoost+2+v2.4

EDIT:

personnaly after a few test i think adding libasound.so make improvement for a louder and clear sound...with external speaker and also with hearphone...

waiting for some backup...in case anybody test that...;) i know twrock will test...

@ twrock...i am actually testing your oc zip with cm6.2-v2

Edited February 23, 2012 by desalesouche

[Guest twrock]

I didn't do anything I'm aware of. Also, the u8220 device folder (where the source for sensors lib is) is the same for 6.2 and 6.1.1 builds. It should be the same for both builds and for all -vX variants of them. I have no clue at the moment...

Definitely need someone else to confirm whether or not your unmodified 6.1.1 has screen orientation working. My tests say not working, but individuals are subject to error.

But (and this is big news for me), I am coming to the conclusion quickly that a huge problem for me with short battery life in CM6 roms (Tom's and your 6.2) has been related to orientation sensor/screen rotation causing the CPU to be forced back to max speed, even when nothing is happening with the phone.

I was getting a huge boost in battery life while using 6.1.1 when compared with Tom's port or your 6.2, and I didn't know why. I was setting everything exactly the same. But now I think I know why. Because the screen rotation was not working in 6.1.1, it was always off (even though I set it to be on). But when it is working (6.2 and Tom's), the battery drain is very noticeable. My guess is that turning of the screen rotation in 6.2 will cause an immediate boost to battery life. (I haven't tested it in TXG/Tom's, but I believe it will be the same there.)

My theory is that the orientation sensor is causing the CPU to run at max the majority of the time. And every time the CPU drops down to idle at the min speed, it is almost immediately forced back up to max speed again. This only happens while screen rotation is enabled. You can turn it off and will probably see the same great battery life I've been getting in 6.1.1.

I can watch this happening in real time by installing a CPU monitor. I simple installed SetCPU, since I want to be able to control the speed anyway. Start SetCPU, set the phone down on a hard surface and watch the current speed on the main screen. Without the phone doing anything, the speed keeps jumping back and forth between the min and max speeds, but will probably spend more time at the max speed. Tap on the Info tab and then Time in State, and you can see how long the CPU has spent in each state. In my case it is spending around 70% of the time at max. (Incidentally, the Android System Info app will also show you percentages for CPU state under the System>CPU tab, but it only shows the static number from when you tap on it; SetCPU will keep adjusting as you watch.)

Next, turn off orientation switching (Settings>Display>Auto-rotate screen). Go right back in to SetCPU and watch it drop immediately to min speed and just sit there. It won't switch back and forth, and over time you will see that it is spending an increasingly higher percentage of the time at min speed. If your use pattern is anything like mine, you will see a marked difference by the end of the day in the percentage of time at min speed and a resultant increase in battery life.

Is this only a CM6 issue or is this true of other roms? Later today I will restore my latest FTB backup and let you know what happens there. FTB has notoriously good battery life, so maybe it doesn't react this same way. Or, maybe turning off screen rotation will give that rom even better battery life. I'm really starting to think that this could very well be why I've never been able to get the "days" of battery life other people have. Maybe they turn off screen-rotation by default. I never have before.

While I started typing this very long post, I turned off screen rotation in 6.2. In the time it took me to type this, the time in state for minimum CPU speed (245) when from 25% to 48% and it is still rising quickly. The results are dramatic!

As always, YMMV, but I hope this helps others. Maybe there is some bug in CM roms that cause this on our phones? Is it related to the screen rotation bug (it gets stuck) that many have reported? :huh:

Edited February 24, 2012 by twrock

[Guest pier11]

I read that akm2d demon, responsible for sensors update, affect very badly battery life. (But it doesn't mean it's not needed :)

W/o it responsiveness of some part of system (compass? - don't remember) start to suffer.

[Guest twrock]

We should decide which is the best combination. I would then either update CM 6.1.1 with GPS icon workaround as in CM 6.2 - or alternatively use new libloc_api in both roms and remove workaround in CM 6.2

Based on my problems with rotation not working at all in 6.1.1, but libloc_api.so resolving the GPS bug in 6.1.1, I'd suggest that you use the new libloc_api in 6.2 and remove the workaround.

If you tell me which files need to be deleted/replaced in 6.2, I'll just do it myself and test that libloc_api does resolve the GPS bug in 6.2 as it did in 6.1.1. Do I assume correctly I can just copy the files from 6.1.1 to 6.2, whichever files they are?

[Guest dr.flo]

Definitely need someone else to confirm whether or not your unmodified 6.1.1 has screen orientation working. My tests say not working, but individuals are subject to error.

I will look at that this weekend.

I was getting a huge boost in battery life while using 6.1.1

...

My theory is that the orientation sensor is causing the CPU to run at max the majority of the time. And every time the CPU drops down to idle at the min speed, it is almost immediately forced back up to max speed again. This only happens while screen rotation is enabled. You can turn it off and will probably see the same great battery life I've been getting in 6.1.1.

I can confirm that switching off screen rotation makes setcpu not indicated that the clock is jumping between min and max. It now stays at min... I wonder though if this has any effect during periods where the screen is off. From my understandig it should always be at "min" during these time.

That would be an awsome find. I rarely use screen rotation but it was always turned on. If just turning it off really boots battery life noticably, it would be a major step forward...

Based on my problems with rotation not working at all in 6.1.1, but libloc_api.so resolving the GPS bug in 6.1.1, I'd suggest that you use the new libloc_api in 6.2 and remove the workaround.

If you tell me which files need to be deleted/replaced in 6.2, I'll just do it myself and test that libloc_api does resolve the GPS bug in 6.2 as it did in 6.1.1. Do I assume correctly I can just copy the files from 6.1.1 to 6.2, whichever files they are?

The workaround on/off cannot be copied over. It is inside framework.apk (which differs between 6.1.1 and 6.2); I will need to comment it out in souce code, and rebuild framework.apk. Then it can be replaced on a running 6.2 rom.

I will do so this weekend, so stay tuned ;)

Edited February 24, 2012 by dr.flo

[Guest twrock]

I wonder though if this has any effect during periods where the screen is off. From my understandig it should always be at "min" during these time.

I can confirm that at least on my phone, with screen rotation enabled, the CPU still runs at max speed most of the time even when the screen is off. I began my tests before going to bed last night. I installed 6.2 and enabled screen rotation. That is why when I started the day, it was over 70% of the time running at max speed. That was after just sitting plugged in overnight, not running anything, not data connectivity of any sort.

I'll run my tests on 2.1 (FTB) in a few minutes to get a comparison.

Edited February 24, 2012 by twrock

[Guest dr.flo]

The workaround on/off cannot be copied over. It is inside framework.apk (which differs between 6.1.1 and 6.2); I will need to comment it out in souce code, and rebuild framework.apk. Then it can be replaced on a running 6.2 rom.

Just remembered that there is no need to rebuild anything: The corresponding file without patches can be extracted from the very first build of cm6.2 I made- it was still in the form of system.img...

I will do this later as said - but if you're really curious, you now know where to get the files earlier.

[Guest desalesouche]

twrock

write /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate 200000 [for some reason Tom had this set to 20000, but his rom is the only place I've seen the number that low, so I concluded it was a typo and changed it]

can you explain the difference between sampling_rate 20000 and sampling_rate 200000? thx

edit:i found these info about cpu sampling_rate... from here http://www.mjmwired.net/kernel/Documentation/cpu-freq/governors.txt

sampling_rate: measured in uS (10^-6 seconds), this is how often you

118 want the kernel to look at the CPU usage and to make decisions on

119 what to do about the frequency. Typically this is set to values of

120 around '10000' or more. It's default value is (cmp. with users-guide.txt):

121 transition_latency * 1000

122 Be aware that transition latency is in ns and sampling_rate is in us, so you

123 get the same sysfs value by default.

124 Sampling rate should always get adjusted considering the transition latency

125 To set the sampling rate 750 times as high as the transition latency

126 in the bash (as said, 1000 is default), do:

127 echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) \

128 >ondemand/sampling_rate

129

130 show_sampling_rate_min:

131 The sampling rate is limited by the HW transition latency:

132 transition_latency * 100

133 Or by kernel restrictions:

134 If CONFIG_NO_HZ is set, the limit is 10ms fixed.

135 If CONFIG_NO_HZ is not set or nohz=off boot parameter is used, the

136 limits depend on the CONFIG_HZ option:

137 HZ=1000: min=20000us (20ms)

138 HZ=250: min=80000us (80ms)

139 HZ=100: min=200000us (200ms)

140 The highest value of kernel and HW latency restrictions is shown and

141 used as the minimum sampling rate.

what is the hz in our diverse rom(cm6.1/cm6.2/cm7.2/um840) ?

[Guest twrock]

Just remembered that there is no need to rebuild anything: The corresponding file without patches can be extracted from the very first build of cm6.2 I made- it was still in the form of system.img...

I will do this later as said - but if you're really curious, you now know where to get the files earlier.

I'll see if I can dig up that first version of 6.2 and copy over framework.apk, and then after verifying the GPS bug is there, copy over libloc_api.so to solve it. (I hope I got that right.)

I tested FTB. It does not respond in the same fashion as CM6. Toggling screen rotation doesn't seem to do anything to the CPU speed control. So it seems that if FTB really has better battery life, it is due to some other reason.

So maybe CM6 with the rotation turned off might give me even better battery life than FTB has been.

Edit: Hmm, no "framework.apk". Maybe framework-res.apk or framework.jar?

Edited February 24, 2012 by twrock

[Guest twrock]

twrock

write /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate 200000 [for some reason Tom had this set to 20000, but his rom is the only place I've seen the number that low, so I concluded it was a typo and changed it]

can you explain the difference between sampling_rate 20000 and sampling_rate 200000? thx

I'm not a programmer or any other sort of expert. But sometimes I just notice things. I noticed that in all of the official boot.img files I extracted for the U8220, the sampling rate was 200000. But Tom's boot.img was set at 20000, 10x's difference.

I had the same question as you, and did a lot of searching on the web. The best I could make out of a lot of technical information was that having the number lower would cause the CPU to vacillate (change) in speed more quickly, and setting it higher would keep it more steady. As I mentioned above in this thread, I was watching the CPU speed jump around a lot and was getting poor battery life. After putting that all together, I reached the conclusion that it was a typo, and changed it. I did ask others about it, including writing a post in Tom's CM6 port thread, but I didn't hear back from him and no one else offered a contrary opinion.

So that's all there is to it from my perspective. Is it saving battery life? Is it slowing down the phone? I really can't prove anything. But since other non-modified U8220 boot.img's have it set at 200000, I don't think it is "wrong". As always, YMMV.

[Guest desalesouche]

I'm not a programmer or any other sort of expert. But sometimes I just notice things. I noticed that in all of the official boot.img files I extracted for the U8220, the sampling rate was 200000. But Tom's boot.img was set at 20000, 10x's difference.

I had the same question as you, and did a lot of searching on the web. The best I could make out of a lot of technical information was that having the number lower would cause the CPU to vacillate (change) in speed more quickly, and setting it higher would keep it more steady. As I mentioned above in this thread, I was watching the CPU speed jump around a lot and was getting poor battery life. After putting that all together, I reached the conclusion that it was a typo, and changed it. I did ask others about it, including writing a post in Tom's CM6 port thread, but I didn't hear back from him and no one else offered a contrary opinion.

So that's all there is to it from my perspective. Is it saving battery life? Is it slowing down the phone? I really can't prove anything. But since other non-modified U8220 boot.img's have it set at 200000, I don't think it is "wrong". As always, YMMV.

thinking you must be right....in which system file is init.qcom.rc? could not find init.qcom.rc. i could only find an init.qcom.bt file in system/etc.

i would like to change it in um840 rom ..i already did with setcpu it was 20000 and i change it to 200000 with uptreshold=95 as you did ..

Edited February 24, 2012 by desalesouche

[Guest twrock]

thinking you must be right....in which system file is init.qcom.rc? could not find init.qcom.rc. i could only find an init.qcom.bt file in system/etc.

i would like to change it in um840 rom ..i already did with setcpu it was 20000 and i change it to 200000 with uptreshold=95 as you did ..

init.qcom.rc is not in a system file. It is in the boot.img itself. So you have to extract the boot.img, which is a process of separating the kernel and a group of files referred to as the ramdisk. One of the files in the ramdisk is init.qcom.rc. After editing it, you must rebuild the boot.img.

I do not change any setting with SetCPU other than the max CPU speed, so I have not set the upthreshold to anything but the default. In most boot.img's I've seen for the U8220, the up_threshold is 76 and the down_threshold is 60 (also set in init.qcom.rc in the ramdisk).

I do all of that kind of work using the dsixda rom kitchen. There are other ways of course, but the dsixda kitchen makes it all quite easy for a non-programmer like me.

[Guest desalesouche]

init.qcom.rc is not in a system file. It is in the boot.img itself. So you have to extract the boot.img, which is a process of separating the kernel and a group of files referred to as the ramdisk. One of the files in the ramdisk is init.qcom.rc. After editing it, you must rebuild the boot.img.

I do not change any setting with SetCPU other than the max CPU speed, so I have not set the upthreshold to anything but the default. In most boot.img's I've seen for the U8220, the up_threshold is 76 and the down_threshold is 60 (also set in init.qcom.rc in the ramdisk).

I do all of that kind of work using the dsixda rom kitchen. There are other ways of course, but the dsixda kitchen makes it all quite easy for a non-programmer like me.

thx a lot...did you have time to test libasound.so and the other file?

[Guest didije]

Hello everyone.

Just needed to mention that in EVERY cm6 rom I have a hard time playing youtube videos in HQ. Sometimes there is only sound but no image and sometimes it just freezes everything. Low quality works well though. The only rom (I mean from later ones) that plays every HQ youtube video is the one from the thread about stock froyo (um840-20120222). But there are still a lot of bugs (the main one is wifi reconection issue) and I really like CM stuff so that one is a no go for me. I really like cm6 clean and TXG and I'm having hard time to chose between the two :rolleyes: They are both just great.

Is it possible for one of you guys to look into this? If you have some free time of course, since that is not very big problem.

[Guest desalesouche]

Hello everyone.

Just needed to mention that in EVERY cm6 rom I have a hard time playing youtube videos in HQ. Sometimes there is only sound but no image and sometimes it just freezes everything. Low quality works well though. The only rom (I mean from later ones) that plays every HQ youtube video is the one from the thread about stock froyo (um840-20120222). But there are still a lot of bugs (the main one is wifi reconection issue) and I really like CM stuff so that one is a no go for me. I really like cm6 clean and TXG and I'm having hard time to chose between the two :rolleyes: They are both just great.

Is it possible for one of you guys to look into this? If you have some free time of course, since that is not very big problem.

to have HQ in youtube go to there http://android.modac...ost__p__1900177 you take in system/lib the following file ( libOmxh264 )from last rom um840-20120222 and you replace it in system/lib of cm6.1 or cm6.2 or cm7.2 (it would work in all these rom):) Edited February 24, 2012 by desalesouche

[Guest didije]

to have HQ in youtube go to there http://android.modac...ost__p__1900177 you take in system/lib the following file ( libOmxh264 )from last rom um840-20120222 and you replace it in system/lib of cm6.1 or cm6.2 or cm7.2 (it would work in all these rom):)

Thank you.It worked :D

[Guest twrock]

Just remembered that there is no need to rebuild anything: The corresponding file without patches can be extracted from the very first build of cm6.2 I made- it was still in the form of system.img...

I will do this later as said - but if you're really curious, you now know where to get the files earlier.

I did it, and have been using the rom today. I'm not ready to pass a verdict, because who knows if I really did it right.

But I have found that the resulting 6.2 rom I am using now is not as stable as the 6.1.1 rom I was using. I will definitely replace it with the next version of 6.2 you upload and test that

Has anyone else tested the 6.1.1 (20120206) rom and found that rotation does not work? If so, dr.flo is there any chance you can find the problem with rotation and fix it so we can compare the two roms together?

[Guest twrock]

Has anyone else tested the 6.1.1 (20120206) rom and found that rotation does not work? If so, dr.flo is there any chance you can find the problem with rotation and fix it so we can compare the two roms together?

Ok, sometimes I just get lucky. ;)

I deleted /system/lib/hw/sensors.msm7k.so, and now rotation works in 20120206-v2 (6.1.1). I have no idea if this is really going to mess up something else, but since the file isn't in 6.2, maybe it doesn't need to be in 6.1.1 either. In any case, it boots and it rotates and it hasn't crashed yet. So I'm back to using 6.1.1, at least for now.

Incidentally, in my testing, the CPU becoming stable only seems to happen when rotation is turned off in Settings>Display>Auto-rotate screen, but does not stabilize if you turn off 90, 180, and 270 rotation in Settings>CM settings>User interface.

[Guest dr.flo]

Ok, sometimes I just get lucky. ;)

I deleted /system/lib/hw/sensors.msm7k.so, and now rotation works in 20120206-v2 (6.1.1).

Big thanks twrock! That's optimal: notice a bug and then provide the solution!!! I did not take the time yet to analyze the issue - but it's not needed at all now, your solution is perfect. I don't know how this file got there. Must be a side effect of manually integrating the u8220 device tree into cm6.

I'm just uploading the -v3 versions of both roms

• using openetna libloc_api.so (the one that was posted already) to hopefully solve GPS related bugs
• removed related workaround from framework as they are obsolete now
• replaced libOmxH264Dec for smooth YouTube HQ video
• fixed screen rotation not working on 6.1.1 (thanks twrock)

Upload will be finished in ~15 min...

I'm currently running CM6bootimg-Starkos691TomRD-528def_swap30.zip on CM 6.2 and did not yet notice any issues...

Edited February 25, 2012 by dr.flo