yashsingh1/xdaforums huggingface dataset:
[Galaxy S I9000 Android Development] dachau:
Thought you were on time-out??
[Galaxy S I9000 Android Development] siky_dude:
This is his time out, wait till you see him on his kernel dedication time.

^^
[Galaxy S I9000 Android Development] Ashtrix:
Newmail, first of all your analysis + the mod for governor was awesome :cool:!

basically actually not a dev and i can't patch my kernel myself (hmm.a noob kinds when it comes to kernel stuff :rolleyes: )

i'm wondering how would be your patch's results vs Smartassv2's coz your patch includes the stuff directly in Ondemand Governor that's a perfect approach making it more effective :eek:.

So, please could you prepare a CWM flashable if possible on behalf of those GPLv2 (idk what are those btw ;) ) or a step by step procedure to perform the FIX .. :o?

Thankyou again for your approach on CPU freq tweak :D !!
[Galaxy S I9000 Android Development] mialwe:
Made a --dry-run patch test, it worked for latest samsung sources with upd-2. Didn't compile and actually use it yet but this reads *very* interesting...
[Galaxy S I9000 Android Development] Ashtrix:
hello newmail!!

that was really a good weekend :p, please can i get any info on the progress:rolleyes:???
[Galaxy S I9000 Android Development] darckengel:
Does someone try to patch the popular kernels (Semaphore/Talon as the sources are available online) and compile it to give a try?
[Galaxy S I9000 Android Development] newmail:
Updated patch with two more cleanups (irrelevant for UP kernels like the Galaxy S one) and renamed to ondemand-cpuidle3.patch

This code worked perfectly here for the last couple of weeks. CPU freq is low as it should be depending on load, and ondemand doesn't go crazy anymore at 1ghz when sampling_rate is set to 10000 (my preferred default and needed for good interactive behavior out of ondemand). The bigger the sampling_rate, the longer time the CPU will wrongfully run at the lowest frequency after you touch the touchscreen or some CPU load is started by apps.

40msec is the galaxy S default and it's too high, this patch alters the default to 10msec (40000 value in sysfs in usec units). But if you lower the sampling_rate without this patch ondemand will misbehave.

The patch also sets the policy.max at 800mhz when screen is off, and policy.min at 200mhz when screen is on, but that's independent of the ondemand changes. It's good default behavior for galaxy S. ondemand can't do magic, so if policy.min is 100mhz the CPU will have to run at 100mhz for the first sampling_rate. Considering other code that this patch disabled was keeping the policy.min at 200mhz at times for apparent no good reason, the policy.min/max changes implemented in this patch when screen is off/on is ideal.

The old name was ondemand-deep-sleep but that was misleading, I figured people uses the name "deep sleep" to mean "suspend-to-ram". What we deal here with ondemand is exclusively the "cpuidle" behavior, where at times the timers won't run for a second when the cpu is idle.
[Galaxy S I9000 Android Development] newmail:
It should apply clean to gingerbread update2 from opensource.samsung.com. It should work for both JVR and JVS but if you fix any reject the ondemand.c part should work for any kernel out there on any cellphone. Any ARM that has a cpuidle that can delay kernel timer interrupts needs my fix. Furthermore the 100msec sampling_rate used by the galaxy S II kernel is not good, it should also be lowered to 10msec like I did in my patch for the galaxy S 1 code, and stick to my fix to prevent ondeamnd go crazy when cpuidle stops the timer interrupts for hugely more than 10msec.

I've been using JVR for months and it works perfectly, I mostly did my own kernel improvements (plus I shut off ram wasters things like nspmobex, drexe, debuggerd by adding "disabled" in the init.rc) without caring much at the userland considering 2.3.4 stock JVR work so good. If I was to change userland I'd switch to cyanogenmod after building it myself from scratch, but I don't have a flash big enough to mess with that, plus I"m not sure how stable and complete it is. I doubt I'll have time to do that any time soon :).

If there was a real simple and generic initramfs change that I could build from source myself, I would at least switch to ext4... I don't want binary blobs, and several months ago when I tried to build the voodoo initramfs myself it just didn't build right.... so I gave it up, luckily stock rfs got more "usable" since then so it's less necessary now. But rfs still much slower and certainly less "unbreakable" than ext4.
[Galaxy S I9000 Android Development] darckengel:
Why do you set min freq at 200Mhz when screen is on?

Without this patch, ma stats say that i stay about 6% at 100Mhz against 1% at 200Mhz, with 200Mhz as min freq, you will drain more battery when phone is awake.
[Galaxy S I9000 Android Development] .:Crack:.:
200mhz and 100mhz use the same voltages, so no higher battery drain.
[Galaxy S I9000 Android Development] stratosk:
Same voltage doesn't mean necessarily same power consumption.
[Galaxy S I9000 Android Development] darckengel:
The voltage gives you the cost of one CPU operation (the more voltage is use, the more energy will be used to do the same thing.

So, if you have the same voltage, you will use 2 times more battery at 200Mhz (200 000 cpu cycles/sec) than at 100 Mhz (100 000 CPU cycle/sec).
[Galaxy S I9000 Android Development] .:Crack:.:
Really? Oh, then nevermind. Somebody told me it would be like i said.
[Galaxy S I9000 Android Development] darckengel:
In your house, all your lights work at 220V, but they will not all use the same power.

It's the same for CPU, (like if 100Mhz was a 100W light and 200 Mhz was a 200W).
[Galaxy S I9000 Android Development] newmail:
this was the answer: "ondemand can't do magic, so if policy.min is 100mhz the CPU will have to run at 100mhz for the first sampling_rate"

To expand it, nothing can do magic, the policy.min, is the slowest frequency you accept to run for the sampling_rate, that means 10msec.

So to reprhase it, the reason is to possibly hope to get a little better interactivity. When screen is on there's a ton of battery drain from all other sources, screen, more chips on like the orientation sensor that eats some cpu etc..

Also note the below:

"Considering other code that this patch disabled was keeping the policy.min at 200mhz at times for apparent no good reason, the policy.min/max changes implemented in this patch when screen is off/on is ideal."

If you install cpuspy you will probably be able to notice after boot or after running a media player and keeping it around in background, the min freq remains fixed at 200mhz even when the screen is off. It will never go below. I suspect the reason they forced 200mhz at all times when some playback is on, is exactly because ondemand can't do magic. And the longer the sampling_rate (default was 40msec) the worse damage it will do to interactivity to start the first sampling_rate at 100mhz vs 200mhz.

It's very possible increasing policy.min to 200mhz isn't needed and we could stick to 100mhz, thanks to the sampling_rate being 4 times shorter now than it was on stock. I just feel 100mhz is slow so I don't like the idea of running at that speed when screen is on.

Also note, usually cpu power goes up exponentially with frequency, so while it's certainly true it will use some more cpu it probably will be a much smaller difference than for the other higher cpu freq level changes.

If you want to disable it to maximize battery even when screen is on, please do.... it's just a matter of adding a "//" prefix at the start of these two lines in the patch:

+ new_policy.min = 100000;

+ new_policy.min = 200000;

(or even more simply set the second line to 100000 :)

In short you may be perfectly right it's worth keeping the policy.min at 100mhz with screen on too, especially now that sampling_rate is 4 times smaller than default (10msec vs 40msec). We need to do some testing to find out simply.

I may actually try to make this change and see if I could possibly notice any difference after using screen on at policy.min 200mhz for a while. I just though the battery drain difference would be long enough. But hey I'm flying tomorrow so I guess it's good time to try this change tonight as I won't be charging the phone for a day... :)
[Galaxy S I9000 Android Development] newmail:
well it's probably certainly not as linear a light bulb :)... but yes it'll use a little more power at 200mhz, if the volt at 100mhz and 200mhz are the same that certainly also mean the energy drain will be similar.

Overall I guess the difference will be tiny in "watts", while in CPU speed it'll be exactly double (at that mhz the ram should be much less of a bottleneck too so the speedup is going to be way more linear than the watt increase). But I'm no arm hardware guru, just guessing from what normally happens... As you boost the frequency further and you need to increase volts to avoid the cpu to go erratic, the drain increases a lot and the performance boost from 800mhz to 1ghz is likely much much less noticeable than the boost from 100 to 200mhz.

Intuitively 200mhz screen on 100mhz screen off sounds ok but I'll give it a shot with 100mhz at all times to see if I can notice any difference in interactivity.

at 10msec sampling rate it means only half the CPU time of a 50hz movement on the screen will be computed at 100mhz, the second half will go at 1ghz.
[Galaxy S I9000 Android Development] darckengel:
Actually, the cpu stacks at 100mhz when screen is on and listening music (i just made the test.

And i don't think staying for 10 or 40ms at 100% of 100 Mhz before reaching the max freq is really noticeable unless you are a droid :)
[Galaxy S I9000 Android Development] newmail:
if you check my patch you will find the code commented out that forced the cpu to stay at 200mhz at all times when some app is running.

In any case with the stock sampling rate of 40msec at 100mhz means the first full frame at 25hz (or first two frames at 50hz) are rendered at 100mhz. With my patch sampling rate goes down to 10msec so probably it's no big deal if we stick to policy.min at 100mhz.
[Galaxy S I9000 Android Development] thunderteaser:
newmail, you are a genius! :) I would really love to see a smartassV2 governor with your deep idle detection. I totally agree on the fact that ondemand is the most used one in many environments and that it should be tweaked to achieve the best from it, but truth is that smartassV2 is already performing better. You would keep ondemand for a balanced juice usage, but implementing didle detection on smartassV2 would totally be the best compromise between efficiency and power saving, imho. I hope there are some developers in the wild interested in picking this up!
[Galaxy S I9000 Android Development] newmail:
:) So I'm currently running the cpuidle detections on all my workstations not just he cellphone. If you cut the changes to the other files and keep only the change to cpufreq_ondemand.c, it'll apply clean to latest upstream kernels.

I'd like if somebody would look into integrating this. In the meantime I also extracted the overclock 1.3G patch and it's now running fine with the 6 levels of frequency (1.3/1.2 levels added). There are no rejects so overclock+ondemand-cpuidle work fine together.

You've to remember however to change the line in drivers/cpufreq.c to set the max at 1300000 instead of 1000000 or the overclock will go away after turning the screen off and on. Besides the whole earlysuspend change in drivers/cpufreq.c could be removed for a more "stock" kernel. I keep the max at 800 mhz when screen is off because I know all my apps need max 800mhz and this way I save a bit of battery when talking on skype with screen off, or while listening to music with screen off.

BTW, interestingly it's not guaranteed that reducing the freq to 800mhz with screen off helps saving battery in any significant way, it's the usual race-to-idle slow-and-steady issue, I think slow-and-steady is a safer bet but it's not guaranteed.

Another thing: since last upload and discussion about it in the above comments, I also commented out the policy->min changes, so the min freq remains at 100mhz regardless if screen is on or off. I couldn't notice interactivity differences with that and it might (or might not if that leads more jumps to policy->max and slow-and-steady wins on this cpu, both variables unknown) save a bit of battery while the screen is on.
[Galaxy S I9000 Android Development] darckengel:
I have a suggestion to support any OC values in the code:

when screen off is detected, save current max freq into a variable, and then set max freq to 800Mhz.

when is screen on is detected, restore the saved variable instead of the hardcoded 1Ghz.
[Galaxy S I9000 Android Development] IDoMy0wnRacing:
noob question...

How is the PATCH applied?
[Galaxy S I9000 Android Development] Rebel2k:
It is a patch for kernel developpers. It must be applied on the source code of kernels. If you want to use it and if you're not a kernel dev, you need to install one kernel which includes it as Semaphore, TalonDev, and so on...
[Galaxy S I9000 Android Development] IDoMy0wnRacing:
Thank you.

I am using TalonDEV so I probably have the patch already and ondemand deep cpuidle detection will probably will be updated with eXistZ’s next release. The tread made for some good reading, so I had to ask.
[Galaxy S I9000 Android Development] zacharias.maladroit:
from what I read on git - it got reverted some Talon-releases ago

seemingly lead to some issues

not sure what exactly

please ask in the Talon thread
[Galaxy S I9000 Android Development] pikachu01:
It got reverted due to it capping OC and then readded with a fix ;)
[Galaxy S I9000 Android Development] stratosk:
I also dropped a part of it because I faced some issues with sampling down factor.

Actually I kept only the part that caps max frequency to 800MHz when the screen goes off.
[Captivate Q&A, Help & Troubleshooting] echodun:
My attempt to flash Gingerbread using odin3 left my phone in a constant non-three button state with red fish and At&t logo. I made a jig which got me into download mode, but now what do I do??? The computer recognizes when the phone is plugged in, but it doesn't show any devices on adb devices. I've also uninstalled and reinstalled the device drivers. Odin3 does recognizes the port of the device and I tried Master Clear but it just set there for awhile. Any help would be appreciated.
[Captivate Q&A, Help & Troubleshooting] Pirateghost:
have you actually done any reading?

in order for you to use master clear you have to be booted into an OS with adb debugging enabled - even says so in the FIRST POST of the Odin one click thread, and is mentioned hundreds of times throughout the forums

adb devices will never see your device in download mode....because its not in a mode that is recognized by adb

since you obviously have odin one click, have you bothered to try and hit the freaking button that just says START?? you know, ONE CLICK.....
[Captivate Q&A, Help & Troubleshooting] echodun:
Okay

The only reason I used master clear was I was desperate as nothing else would work. Should I just run I897UCFJ6-final then, click start and don't attach any other files? Will that enable my phone to boot properly at least so I don't see the crazy red fish over and over again?
[Captivate Q&A, Help & Troubleshooting] xTRUEx:
just odin one click, and you are golden
[Galaxy S I9000 Q&A, Help & Troubleshooting] ErsdaHL:
did not have this problem befor flashin jvs but now when im charging it indicates 100% battery and directly when i unplug it it goes down to 97 did not do this before flashin 2.3.5 and I even flashed 2.3.4 now! I managed to get 98 by disconnecting and connecting charger many times. Why?
[Galaxy S I9000 Q&A, Help & Troubleshooting] zcarguy:
I have darky's 10.2 Exrtreme or final - can't remember

I have the same problem. But even worse mine sometimes only charges to 60 or 65%. I can get a full charge after several unplugs and re-plug but it takes a while.

The big problem is once it fully charges it seems like the phone stops charging completely and then begins to drain out - should it not maintain the full charge even if left charging at full?

Any help please.

Thanks
[Galaxy S I9000 Q&A, Help & Troubleshooting] MrIwik:
This is normal, no need to panic.

This is not normal, although a known and common bug.
[Galaxy S I9000 Q&A, Help & Troubleshooting] zcarguy:
my phone is using build jvq -not sure if that makes a difference. I am new to all of this. Had a friend help me with the flashing. Anyway I didnt think my issue was normal - its a pain because when I charge my phone overnight - I cant simply unplug and take it away with a full charge.

Any ideas how to rectify this?

Thanks,

Z

Originally Posted by zcarguy View Post

I have darky's 10.2 Exrtreme or final - can't remember

I have the same problem. But even worse mine sometimes only charges to 60 or 65%. I can get a full charge after several unplugs and re-plug but it takes a while.

The big problem is once it fully charges it seems like the phone stops charging completely and then begins to drain out - should it not maintain the full charge even if left charging at full?

Any help please.

Thanks

This is not normal, although a known and common bug.
[Galaxy S I9000 Q&A, Help & Troubleshooting] ali_khalid5518:
Hay fellas easy easy....one thing do u send me ur battary usage pic...hope i could help u and then i can easily understand ur problem...u can pm me.i hope this is not big prob
[Galaxy S I9000 Q&A, Help & Troubleshooting] ErsdaHL:
Exactly the same problem ive got. Manage to get 98%

It happend in 2.3.5 ant following in to 2.3.4

Your problem seems to be a boner compared to mine !!

im not on darkys im on tornado right now!
[Galaxy S I9000 Q&A, Help & Troubleshooting] ali_khalid5518:
Well dude 97% is normal i m just asking to guys who hav 65%.
[Galaxy S I9000 Q&A, Help & Troubleshooting] zcarguy:
I did some more reading. Apparently my problem is a bug with respect to SGS and gingerbread. Once the phone reaches full charge - it stops charging and even though its still plugged in. At this point the phone drains (presumably like normal depending on what you have running in background).

At this point the only fix is to flash back to froyo or I think charging the phone while powered off would work too. Not much of a fix but at least when I wake up in the morning its fully charged.

For others with the same problem as me see this thread:

http://xdaforums.com/showthread.php?t=1134741

If anyone else has a better alternative I am all ears.
[Android Software/Hacking General [Developers Only]] arpruss:
Does anyone know how to do library interposition on Android? The usual way for Linux uses LD_PRELOAD, but LD_PRELOAD is not supported on Android. I know it can be done because ChainFire3D does it.

One of the things I'd like to interpose is libskia.
[Android Software/Hacking General [Developers Only]] arpruss:
I just tried the following. Rename libskia.so to libskia.so.0 and create a new library called libskia.so that just tries to load libskia.so.0:

#include <stdio.h>
#include <dlfcn.h>

void* handle = NULL;

void __attribute__ ((constructor)) my_init(void) {
handle = dlopen("/system/lib/libskia.so.0", RTLD_GLOBAL);
}

void __attribute__ ((destructor)) my_fini(void) {
if (handle != NULL) {
dlclose(handle);
handle = NULL;
}
}

Compile with:

arm-none-linux-gnueabi-gcc -shared -o libskia.so interpose.c

Install libskia.so.

Doesn't work: zygote doesn't start up.
[HTC EVO 3D] shook187:
Is it just me but i'm envying all the Epic touch owners. I now feel like my 3d is 2nd rate only after owning it for 2 months :(
[HTC EVO 3D] Drewmungus:
It's called hype. They both pretty much on par with one another spec wise except the 3D has 3d and a higher resolution screen. Remember that iphone hype you resisted when you got a 3D it's the same thing
[HTC EVO 3D] Saleenfiend:
Don't worry about it.. next week you'll have a third tier phone the way this industry is speeding up haha.

I'm sure the SGSII is great and I want one... I'll probably end up buying on when they starting popping up on Craigslist so that I can check out Samsung's phones (I've always had HTC). Your phone is great... and really not too much different
[HTC EVO 3D] swaze:
Yea its just you

Sent from my 3d pimpin CM7
[HTC EVO 3D] Uchennadi:
Here are some sayings to consider. lol.

Another man's trash is another man's treasure.

You don't know what you have until its gone.

You always want what you can't have.

And the most applicable here, patience is virtue.

And a counter saying to the above ones as it applies here,

The grass is always greener on the other side.

#realtalk

I know this ain't twitter, but wth lol
[HTC EVO 3D] cajones42:
yep, just you. we have the best phone htc can make and the benchmark for every other company. this is the same thing that happend when the droid x came out when i had the og evo. i didnt miss anything with it and i wont miss anything with my 3d. both phones will do the same thing, o nevermind the sg2 cant do 3d lol. i guess they are stuck with a 2d pixilated version. :)
[HTC EVO 3D] poloboogie:
yeah ive had the sg2 for about 4 months now(unlocked version of course) but there was just something telling me that i wanted a evo 3d so as soon as the gsm version was available i jumped on it my thoughts were as follows i was going to have both of them one day i would put the sim card in one and the next day switch back to the other one. the sg2 has a beautiful screen and even though it views 1080p video which when playing you cant really tell that the 3d has a higher resolution. it has 16gb internal and i have a 32 gb sd card, so i got movies galore, no music though since i dont beleive in cd's anymore all the music is on my 32gb iphone 4 lol. now back on subject to me it was a win win situation, the best of both worlds ive had my 3d for about a month now and long story short sim card has been in it everyday. trust me you're not missing anything
[HTC EVO 3D] evohog:
I felt like that when the epic came out, got one and wanted to kick myself in the ass for doing so. The epic touch is cool now but in a couple of months when updates start rolling out and the forums are full of pissed off touch owners at no updates you'll be glad you have HTC. It could be different this time but I'm leaning towards not. Anyways my 2 cents :)

from my 333dddeeevvvooo
[HTC EVO 3D] SolsticeZero:
I played with the Epic Touch, and I can say I prefer the Evo 3D. QHD >>>>>> HDPI. The screen on the touch feels so bloated with the huge icons and fonts. Plus, my god, you can see the pixels. It's downright ugly. The Amoled is nice, but it's not worth it for that loss of resolution.
[HTC EVO 3D] jenna728:
Exactly! The screen may be more vibrant but I would take 3D and QHD over better colors any day.

I played with the ET4G for a few hours yesterday when my bf picked one up, its not noticeably better or "lightyears" ahead like some are claiming. I couldn't even tell the difference speed wise. All I know is my 3D actually feels like a high end device, the Epic Touch feels like cheap plastic. Speakers were definitely better but the resolution and feel was a deal breaker for me. He returned it for another 3D.

I'm glad I got to try it out but I would have regretted trading for one. I'll wait for the Nexus or something.
[HTC EVO 3D] Wiley_11:
Oh get a grip. :p They're both great phones and they both have issues to one degree or another. :D
[HTC EVO 3D] BrianBaker:
If you're the type that likes keeping up with Android and are only content with the latest and greatest.You may wan't to make some more money and buy the phones as they drop every month or two.No way you will keep up and be happy on subsidized deals...

Dont go chasing Android waterfalls my friend.
[HTC EVO 3D] AyoJake:
i kinda felt the same when the epic came out when i had the evo 4g but then saw samsung pretty much abandon them so im not worried i wont buy a samsung phone until they prove they can update the phones they release.
[HTC EVO 3D] ms79723:
Of course you're envying that sht...that's because it's a new high end phone and you don't have it. Just ignore it.