Database Info

Proposal for mod rom versioning

One of the big issues I have noticed is that there is no rationale behind the version number assignment for a lot of the mod firmware. There are different modders using their own versioning, and there isn't even a hint of what version of android they are using, so we have things like;
"KiNgxKxROM Version 1.1r1"
"The Official Blur - Hero-V1.5.7 by Drizzy"
"JACxHEROSkiv2.2"
"CyanogenMod 4.1.11.1"
*** these all have the same problem... what version of android do they correspond to? How new IS each one of them?
I would like to propose a new standard to be adopted by everyone.
name-officialversion-modversion.
Of the form i.e.
"superxmod-1.6.DRC83-0.1.0.0"
***WHERE the modversion RESETS TO ZERO each time the official version increases, so for example, "CyanogenMod 4.1.11.1" should be called "CyanogenMod-1.6.DRC63-0.1.11.1".
* this will allow the user to immediately know where this rom comes from in terms of the official android versions and approximately how old it is.

I do my best
I do my best ... with the "limited space" we're given for Thread Titles on the forum.
~enom~

I support this though I find it unnecessary. The new beginner user will most likely READ atleast the first post of the thread and they will know what the ROM is based off of. The end user will of course know to read the thread before doing any flashing of any kind so organizing mod rom versioning isn't a necessity. It's convienent but not necessary

I support this because it would make ROM catalogs easier to build, which would benefit the whole community.

why not just post what android version the rom is based on in the first post. First post should always hold the most info anyways.

Since this thread hasn't been moved from the Dev section so far.
+1 for the versioning.
Also, how about we all stick to one benchmarking app (or is there any one app that we CAN rely on)
to test performance of ROMs, so that there's an objective way of figuring out
whether the latest frankenROM (thanks devs! ) is faster than X or Y?
Benchmark Pi has a score that's difficult to figure out, seeing as it throws up an
awesome number on a fairly sluggish HERO whereas the score for a fast-as-light
cyan ROM is way way worse. I know that Benchmark Pi isn't the answer,
not by a long shot. So is there a better alternative out there?
I'm tired of posts that go "THIS IS WAY FASTER! THANKS!" only to find
that the supposed speed increase is more rooted in perception than in
reality.
We need definitive numbers for ModelNumber+ROMVersion+CC/SwapSettings combinations.
Any help?

alritewhadeva said:
The end user will of course know to read the thread before doing any flashing of any kind
Click to expand...
Click to collapse
rofl. Funniest thing i've read all week.

+1
how about shorthand naming such as
for example:
CyanogenMod = CM-AOSP1.6r1-v4.20

If you're talking about cyanogen mod, you might want to add a couple more zeroes at the end. Anyway, I had proposed this too a while ago. I like your format, and I'll go one better; let's do cook-androidVersion-buildVersion-feature.bugfix
for example, the build I made this morning would be "jm-1.6-Donut eng.jubeh.20090930.070211-0.0"
jm is what I use for my builds (short for jubehMod)
1.6 is the current android branch (as per build.prop, no 1.6_r1 yet)
Donut eng.jubeh.20090930.070211 is the build number the compiler assigned to my build, people who work off of modding factory releases or build for dream_open are the ones who usually come up with things like CRC or DRC etc, I build for "AOSP for Dream" (it's a new "vendor" added)
first 0 is feature number, at this point my build is nothing but stock AOSP donut, no Google apps, no a2sd, no netfilter, no compcache, no bfs, just stock donut, so say I were to add a2sd, then I'd go up to 1, as I would have added one or more features (and this would be listed at the change log), basically, anything added that improves the build (and that's not a fix) is a +1 to feature
second 0 is bugfix. For example, right now my build works correctly in every sense, but I have a problem with the video camera where video is of very poor quality (real problem, I'm trying to figure it out), so say i get it fixed, then my bugfix number would go up 1, so basically, anything changed in the build strictly because it didn't work as intended is a bugfix
the last two numbers would be allowed to go past 9, so no more pressures to add .1s at the end like cyanogen was doing to prevent jumping to build # 4.2

karthikjr said:
+1 for the versioning.
Also, how about we all stick to one benchmarking app (or is there any one app that we CAN rely on)
to test performance of ROMs, so that there's an objective way of figuring out
whether the latest frankenROM (thanks devs! ) is faster than X or Y?
Benchmark Pi has a score that's difficult to figure out, seeing as it throws up an
awesome number on a fairly sluggish HERO whereas the score for a fast-as-light
cyan ROM is way way worse. I know that Benchmark Pi isn't the answer,
not by a long shot. So is there a better alternative out there?
I'm tired of posts that go "THIS IS WAY FASTER! THANKS!" only to find
that the supposed speed increase is more rooted in perception than in
reality.
We need definitive numbers for ModelNumber+ROMVersion+CC/SwapSettings combinations.
Any help?
Click to expand...
Click to collapse
yes just bench mark. its much better than benchmark pi only test the cpu really

by the way, I've been saving pretty much all roms that have been posted here (notable exceptions are haykuro's, jf's, and theduded's roms, I haven't been here THAT long) and I have them all saved on my computer separated by /cook/build/ for the Dream roms and /build/cook/ for the Hero ports. I guess I could run a quick filesystem lister and upload that list for people to see so they can sort of get an idea what mod release corresponds to what build

Here we go, I had to upload it inside a zip because of the stupid 2kb limitation on text files (this is 10kb)

lbcoder said:
One of the big issues I have noticed is that there is no rationale behind the version number assignment for a lot of the mod firmware. There are different modders using their own versioning, and there isn't even a hint of what version of android they are using, so we have things like;
"KiNgxKxROM Version 1.1r1"
"The Official Blur - Hero-V1.5.7 by Drizzy"
"JACxHEROSkiv2.2"
"CyanogenMod 4.1.11.1"
*** these all have the same problem... what version of android do they correspond to? How new IS each one of them?
I would like to propose a new standard to be adopted by everyone.
name-officialversion-modversion.
Of the form i.e.
"superxmod-1.6.DRC83-0.1.0.0"
***WHERE the modversion RESETS TO ZERO each time the official version increases, so for example, "CyanogenMod 4.1.11.1" should be called "CyanogenMod-1.6.DRC63-0.1.11.1".
* this will allow the user to immediately know where this rom comes from in terms of the official android versions and approximately how old it is.
Click to expand...
Click to collapse
................................

Hi jubeh,
Thanks, this kind of cataloging is exactly why the OP's suggestion will be helpful.

karthikjr said:
We need definitive numbers for ModelNumber+ROMVersion+CC/SwapSettings combinations.
Any help?
Click to expand...
Click to collapse
I'm not so sure that we do...
I think that that should be more of a "details" thing.
Maybe we can go with "name-officialversion-modversion[-custom]" (square braces mean optional). Name might be a good place to keep modelnumber (I assume you mean by that "dream", "magic", "hero", etc.),
i.e.: supercustomrom(DREAM)-1.6r1-0.0.0.0.0.0.0.1-cc_swap_a2sd

[App] Galaxy Tuner (IO scheduler, LCD color, Sound(Hw Eq), Memory Manager, OC...)

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
This application is made for enhancing or changing some feature for galaxy S
Requirement
1. machine
galaxy S (all variant)
2. version
Froyo (kernel 2.6.32.9)
3. rooted phone*
(*After checking "use with unrooted" option, you can remove rooting)
Feature
1. IO scheduler change
It can change CFQ(default) to deadline for some block device.
This change affect response time of disk IO.
(If you are using the application which handle many small files. You can feel better responsive reaction)
2. LCD color adjustment
(Test version)
This can be helpful to adjust so blue or yellow LCD.
3. Sound (3D, Hardware Equalizer)
It affect all system sound. so, If you change some parameter, all system sound(music, movie, radio..) will be affected.
How to test.
When you are hearing the music, As soon as changing the parameter, you hear different sound.
4. Memory Manager
Because It is controlled by kernel and android framework, It is more powerfull and efficient then memory killer.
for more info visit this link (thank to androcheck)
http://forum.xda-developers.com/showthread.php?t=622666
5. Over Clock (1.2Ghz)
OC feature is harmful to your phone. so, I put some restriction for preventing abuse.
(OC kernel user do not use this feature. I didn't consider OC kernel. and, I don't know about OC kernel)
6. Firmware(kernel) writing
you can write kernel(zImage) directly. and. can enter into recovery,download mode via this app.
7. use this app with unrooted
(Fort this. you must check "use with unrooted" option. before unrooting)
8. Bad block check (for ext filesystem)
If There are bad blocks on your ext filesystem. You can experience lag,abnormal app exit,slowness
9. key(Button) remaping Feature added
Volume Up,down key can be remapped to other key. (This is tested on M110S)
10. Touch gesture
It can map total 6 key button with Touch gesture.
11. Orientation Fix (especially Landscape mode)
It is helpful to view Landscape lying
How to download
search with this keyword on the market (galaxy tuner or d.w.kim)
Technical note
* LCD color and Sound function is accessing chipset resister directly.
* because, I don't have mDnie(LCD), wm8994(Sound) datasheet. I could not implement many feature.
* all system changing is volatile. so, If you reboot your phone. all system state is identical to original state
* OC function in this app change governor(performance, conservative..) policy. so, consider changing governor policy from like set cpu app
* running without rooting is a little tweak. It still require root privilege.
* more detail technical note
http://blog.naver.com/dowkim10/120122503306
* more about sound Howto
http://forum.xda-developers.com/showthread.php?t=921736
(Thanks to supercurio and studiominal)
Version note
1.3
The first version for all galaxy variant.
1.4
memory manager feature added
1.5
- color, sound (on boot adoption)
- memory manager (add some reinforced feature)
- bug fix for voodoo 5.2 patched kernel user (previous user must reboot once or reinstall for working)
1.6
OC (Over Clock 1.2Ghz) feature added
1.7
working on unrooted state.
1.8
Firamware(kernel) writing Feature added.
1.9
Bad block check(ext) Feature added
2.0
key(Button) remaping Feature added
fix bug (running Galaxy Tuner service at any time)
2.1
Orientation Fix (Feature added)
Sound (add option)
(it will clear user sound profile)
Memory Manager (Enhancement)
bug fix (on boot adoption is not worked sometimes)
2.2
Memory Manager (add VM control)
Key mapping( more button mapping added)
2.3
key mapping(Power key as Power+ headsetHook)
touch gesture feature added
Bug note
beta test version note
It is pre version for testing bug fix and add-on feature before releasing market
try attached file

Thanks dw kim. The app is amazing. I tried it with a couple of Mr Big songs. Is it like a parametric equaliser? Anyway, it's amazing how bassy it can achieve. The color temperature is great, I've always thought colours of my pictures were way too greenish, now I can adjust it to look more natural. Any way we can save it as boot settings?

Thank you very much.
I'm very happy It's working on your phone.
(You are first user except korean)
According to wm8993 manual(I don't have wm8994 manual). It is parametric equalizer.
It does not support on boot setting.
(but, I consider this function. I suggest you saving and loading user profile)

Haha, I am glad I am the first customer. Yes, the user profiles helps a lot.
Well, I think Supercurio, maker of Voodoo kernel, (maybe you already know him) has the Wolfson WM8994 manual? You could try ask him, he has a thread about sound here.
http://forum.xda-developers.com/showthread.php?t=806195
Btw, my phone is the international I9000.

Thanks a lot.
but, I don't have update plan right now, and I know him as very famous people.
so, I don't want to bother him.

No worries, dw kim, he's super helpful guy! Okay, relax, that app will make many ears happy already.
Btw, my favourite settings is +9, +6, +5, +7, +11. I think it's perfect. Using stock SGS earpiece.

It is too high gain.
How about extracting constant value on every band. and, volume up. (maybe same effect)
Too high value can make sound noisy

3d sound doesn't seem to work. o_0
one more thing: I'm using bluetooth A2DP.

stfudude said:
3d sound doesn't seem to work. o_0
one more thing: I'm using bluetooth A2DP.
Click to expand...
Click to collapse
This application access Sound chipset register directly. It is not software Equalizer.
If sound stream is transfered via bluetooth devcie. (without path of sound chipset)
you can not experience sound effect.
How about earphone or headphone ?
What is your phone model?

Great app!!!
Is there any posilibity to make it "autostart"...?
every time i reboot my phone I have to turn the settings on...

pandomu said:
Great app!!!
Is there any posilibity to make it "autostart"...?
every time i reboot my phone I have to turn the settings on...
Click to expand...
Click to collapse
I am considering. It is not difficult to implement.
(IO scheduler menu has this option)
but, I am afraid to add this option (LCD, Sound)
because, It handle hardware.
If There is no special case (after changing Sound, Phone is died)
I will add on boot option.
This application is not background application or service.
After setting a sound parameter, you can kill or remove from memory.

Just reporting that it works perfectly well with international GT-I9000 version.
For me, CFQ scheduler works best.

Thanks very much, i haven been waiting months for this
Hi Dowkim,
Thank you very very much. I have been waiting months for an application to adjust LCD color, but i had to either flash a kernel or accept that the camera stopped working. Your app works perfectly, thank you!
A suggestion: in the screen when adjusting color, you could add a colour testpattern so one can see the effect of the changed colors immediately.
Galaxy 9000 International Speedmod Rom

pwhooftman said:
Hi Dowkim,
Thank you very very much. I have been waiting months for an application to adjust LCD color, but i had to either flash a kernel or accept that the camera stopped working. Your app works perfectly, thank you!
A suggestion: in the screen when adjusting color, you could add a colour testpattern so one can see the effect of the changed colors immediately.
Galaxy 9000 International Speedmod Rom
Click to expand...
Click to collapse
Thanks. That is good idea.
I'll try. (but, I am poor at android programming)

dowkim10 said:
(but, I am poor at android programming)
Click to expand...
Click to collapse
I didn't notice for sure

Awsome work on this app. The music controls all work perfectly and make a huge difference in volume which i always thought was to low.

Hi dowkim10, this is interesting work.
I thought a lot about how to design the Voodoo sound driver and the consequences of the design chosen.
I took a different approach than yours: coding also a new driver, not as an independent .ko but using hooks in the actual source of the sound drivers to stay portable.
I believe a few limitations of the design you use are :
- It will be hard to add improvement like the microphone input auto-gain I prepare for the next version.
- Same thing for the FM radio bass solution
- Next to impossible for the upcoming audio jitter issue resolution
- Pretty hard and encumbered for adjusting other various input/ouptut gains/levels here and there
As kernel modules, like the scolor.ko and ssound.ko have a lot of power, in theory everything is possible but Galaxy S devices have so much different versions that implementing a module overriding some functions from the actual driver without breaking anything on a device or another will probably lead to very dirty code and headaches to maintain.
I thought of implementing everything using the wm8994_write dynamic register rewrite technique described here, also by inserting .ko modules like you do.
But here is what's in Voodoo sound source code:
https://github.com/project-voodoo/l...-voodoo/Kernel/sound/soc/codecs/wm8994.c#L215
https://github.com/project-voodoo/l.../Kernel/sound/soc/codecs/wm8994_voodoo.c#L270
By sniffing sequences of register address / value pairs, you should be able to recognize some patterns and add custom changes into it to extend your implementation.
But again, quite a dirty design
Good think of course it's the awesomeness of not requiring a custom kernel.
Of course my approach requires to publish every single piece of Kernel work as GPL and convince a lot of kernel developer to apply these patches, including eventually Samsung and Google.
But it's how I like it
As you distribute and insmod .ko modules, you're not forced to release source for them, but I advocate for Open Source.
Also, you will find a lot more code and ideas you will be able to re-use in the next Voodoo sound versions, about how to handle the parametric EQ and avoid saturation, and a lot of things like that.
Again, GPL will be a lot preferable.
bug report: mDNIe settings you use are lost after running Video player, Camera application (every app sending new mDNIe settings affecting the color response)
PS: don't be afraid to contact me, I am 70% of the time connected to IRC to discuss with and provide support to users and developers in real time.

dowkim10 said:
This application access Sound chipset register directly. It is not software Equalizer.
If sound stream is transfered via bluetooth devcie. (without path of sound chipset)
you can not experience sound effect.
How about earphone or headphone ?
What is your phone model?
Click to expand...
Click to collapse
International I9000

supercurio said:
Hi dowkim10, this is interesting work.
I thought a lot about how to design the Voodoo sound driver and the consequences of the design chosen.
I took a different approach than yours: coding also a new driver, not as an independent .ko but using hooks in the actual source of the sound drivers to stay portable.
I believe a few limitations of the design you use are :
- It will be hard to add improvement like the microphone input auto-gain I prepare for the next version.
- Same thing for the FM radio bass solution
- Next to impossible for the upcoming audio jitter issue resolution
- Pretty hard and encumbered for adjusting other various input/ouptut gains/levels here and there
As kernel modules, like the scolor.ko and ssound.ko have a lot of power, in theory everything is possible but Galaxy S devices have so much different versions that implementing a module overriding some functions from the actual driver without breaking anything on a device or another will probably lead to very dirty code and headaches to maintain.
I thought of implementing everything using the wm8994_write dynamic register rewrite technique described here, also by inserting .ko modules like you do.
But here is what's in Voodoo sound source code:
https://github.com/project-voodoo/l...-voodoo/Kernel/sound/soc/codecs/wm8994.c#L215
https://github.com/project-voodoo/l.../Kernel/sound/soc/codecs/wm8994_voodoo.c#L270
By sniffing sequences of register address / value pairs, you should be able to recognize some patterns and add custom changes into it to extend your implementation.
But again, quite a dirty design
Good think of course it's the awesomeness of not requiring a custom kernel.
Of course my approach requires to publish every single piece of Kernel work as GPL and convince a lot of kernel developer to apply these patches, including eventually Samsung and Google.
But it's how I like it
As you distribute and insmod .ko modules, you're not forced to release source for them, but I advocate for Open Source.
Also, you will find a lot more code and ideas you will be able to re-use in the next Voodoo sound versions, about how to handle the parametric EQ and avoid saturation, and a lot of things like that.
Again, GPL will be a lot preferable.
bug report: mDNIe settings you use are lost after running Video player, Camera application (every app sending new mDNIe settings affecting the color response)
PS: don't be afraid to contact me, I am 70% of the time connected to IRC to discuss with and provide support to users and developers in real time.
Click to expand...
Click to collapse
Hello supercurio
First, I am honored to meet you.
I know someone in korea said existence of this application. and, talked with you.
I also know you did very great job on galaxy kernel.
When I saw your sound code and mDnie code. I think you developed all passion and soul with many trial and error.
Absence of document maybe a excuse.
I have worked for ten years on embed linux. and treating many architecture(arm, ppc,mips,x86.) and treating kernel from 2.2 (now 2.6)
and, a few years ago, I ported android kernel to many board(arm v5,6,7 and xscale) and implemented HAL layer(GPS, alsa, bluetooth..) (android 1.0 around)
but, now I don't have relation Android in my job. so, I am doing this for my hobby. (I don't have enough time)
I know the risk of kernel module. wrong code or accessing bad address can cause system dieing.
but, basically, built-in and kernel module is same.
And, I didn't use your code. this module is treating only a few register.
Anyway, I am very nice to meet you. and many thanks for your advice.
( I hesitated to contact you. I'm a little shy)
If I keep my composure. I'll contact you via IRC.
Thank you.

dowkim10 said:
Hello supercurio
First, I am honored to meet you.
I know someone in korea said existence of this application. and, talked with you.
I also know you did very great job on galaxy kernel.
When I saw your sound code and mDnie code. I think you developed all passion and soul with many trial and error.
Absence of document maybe a excuse.
I have worked for ten years on embed linux. and treating many architecture(arm, ppc,mips,x86.) and treating kernel from 2.2 (now 2.6)
and, a few years ago, I ported android kernel to many board(arm v5,6,7 and xscale) and implemented HAL layer(GPS, alsa, bluetooth..) (android 1.0 around)
but, now I don't have relation Android in my job. so, I am doing this for my hobby. (I don't have enough time)
I know the risk of kernel module. wrong code or accessing bad address can cause system dieing.
but, basically, built-in and kernel module is same.
And, I didn't use your code. this module is treating only a few register.
Anyway, I am very nice to meet you. and many thanks for your advice.
( I hesitated to contact you. I'm a little shy)
If I keep my composure. I'll contact you via IRC.
Thank you.
Click to expand...
Click to collapse
Hi! be sure the honor is shared.
Thanks for your answer,
I see you not only speak Korean and English languages with ease but also I2C at least
Yes the absence of any sign of documentation about mDNIe forced to use the reverse-engineering approach ^^ as I had no experience in Kernel development a few months ago it was a lot of trial and error.
Now Samsung have given a little details in their new source code release about mDNIe controls, which is definitely a move in the right direction.
I'll try to get the doc for this chip.
I agree the first Voodoo sound implementation was crude, that's why I never activated and rewrote it from scratch for the release.
You're a much more experienced kernel and embedded developer than me!
Come on, don't be so shy, I'm just a rookie compared to you
See ya!

[OUTDATED AND REMOVED BY KIFNO] Kifno's Scripts v2.x.x Series

Kifno's HeroC Universal Scripts v2.0.1
PLEASE READ THE ENTIRE FIRST POST BEFORE POSTING
THE CREDITING/PERMISSION ISSUE IS DONE AND OVER WITH EVER SINCE THE V1.x THREAD SO PLEASE NO MORE POST ABOUT THAT, OR YOU WILL BE REPORTED TO A MOD! ALSO I DID NOT JUST COMPILE A BUNCH OF MODS TOGETHER! IF YOU READ THE CREDITS YOU'LL SEE I ASKED TO USE THEIR IDEAS AND I IMPROVED THEM AND INCLUDED THEM ALONGSIDE MY WORK! SO PLEASE NO POST ABOUT I HAVEN'T DONE ANYTHING BECAUSE IT IS OFFENSIVE TO ME WHEN I KNOW I HAVE DONE EVERYTHING IN THIS SCRIPT FOR OUR HEROES, FROM MY CUSTOM VALUES TO THE IMPROVEMENTS OF OTHERS IDEAS OF WHICH I HAVE CREDITED AND GOT PERMISSION FROM AND SUBMITTED MY IMPROVED VERSION TO.
Thanks
- Kifno​
What did I do?
- Read change log
My Explanation for the tweaks/scripts
Code:
Yes these are the tweaks I apply. They are what I think are the best
values for the file(s). Now I'll go into detail as to what each file is and why I set
a new value for it. If you don't like my opinion as to why my new value is
better please explain in a positive manner why you think so or just well...
then, no offense but just keep it to yourself. If you can't say anything
that is constructive POSITIVE critism without using language that could lead to
an argument/provakative language then please don't post here. Now on to the
explanations.
[B]Kernel Tweaks:[/B]
This specifies a period of time that the kernel gives a process that is holding a
file lease. After it has sent a signal to that process notifying, it that another
process is waiting to pen the file. In simpler terms this means that the kernel
has given the process a set amount of time it can hold a file after another
process has notifying it that it wants the file. The deafult had the time higher. I
set it lower. Although it doesn't make much of a difference, ever millionth of a
second counts :D
[CODE]/proc/sys/fs/lease-break-time
This enables cfq compatibility with older kernel models. This results in better
performance, for example more smoothness in apps and the launcher
Code:
/proc/sys/kernel/sched_compat_yield
This value has to correspond with the file-max value so this is raised according
to the value of the file-max. Why did I raise the file-max? Keep reading silly
Code:
/proc/sys/kernel/ngroup_max
Disables some annoying cfs scheduler feature (which is why I don't use the cfs
scheduler in my tweak, I use the noop scheduler) whic increase the UI's
performace just a bit.
Code:
/proc/sys/kernel/sched_features
Sets the maximum number of file-handles that the android kernel will put aside
for other use, share, or put in memory for other use. Usually increasing this
value is a good thing compared to the default value. Which in our case, it was.
If our kernels had an inode file we'd want the value of that to be 2-3 times as
much as the file max. Its a good tweaking rule I thought I'd let you know just
in case you're on linux
Code:
/proc/sys/fs/file-max
This is the max percentage of active processes that can be filled with dirty
pages before the pdflush begins writing them This MAY OR MAY NOT be the
default value for most kernels, but just in case it isn't I set it anyway. Why?
Becuase I want to make sure that if the dirty pages is about 19MB - 40MB of
our RAM, that pdflush begins writing
Code:
/proc/sys/vm/dirty_background_ratio
How agressively memory is "swapped" between disk and swap space.
Code:
/proc/sys/vm/swappiness
Lowering this is a good thing if on a system with slow I/O speeds between the
disk. But if this is lowered too much the I/O will get "constapated" and just
slow the phone down.
Code:
/proc/sys/vm/dirty_expire_centisecs
Doesn't do much but messing with the pdflush's timing of things. Little improvement but everything adds up
Code:
/proc/sys/vm/dirty_writeback_centisecs
Management of the phone's processes by setting a max amount of memory the
phone allows for dirty pages before stopping the processes writing.
Code:
/proc/sys/vm/dirty_ratio
Sets kernel priority for getting/releasing inodes and dentry cache files.
Higher = getting inodes and dentry cache files back more quickly
Lower = releasing inodes and dentry cache files a bit more quickly
Code:
/proc/sys/vm/vfs_cache_pressure
Changes the govenor depending on screen state
Code:
$*GOV
Changed timeslice lenght for better performance when using the phone, and
bettery battery when you aren't using the phone (screen off).
Code:
/proc/sys/kernel/sched_latency_ns
/proc/sys/kernel/sched_min_granularity_ns
/proc/sys/kernel/sched_wakeup_granularity_ns
Cpu frequencies. Pretty simple to explain
Code:
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
Amount of time before the interactive governor decides to change the cpu
speed.
Code:
/sys/devices/system/cpu/cpu0/cpufreq/interactive/min_sample_time
This is how often the kernel changes the frequency.
Code:
/sys/devices/system/cpu/cpu0/cpufreq/conservative/sampling_rate
This is the max rate at which the kernel can change frequencies.
Code:
/sys/devices/system/cpu/cpu0/cpufreq/conservative/sampling_rate_max
Thi is teh min rate at which the kernel can change frequencies.
Code:
/sys/devices/system/cpu/cpu0/cpufreq/conservative/sampling_rate_min
Average CPU usage from kernel's sampling rates which help it determine
wheather or not it should increase the CPU frequency.
Code:
/sys/devices/system/cpu/cpu0/cpufreq/conservative/up_threshold
This is what I use to find the battery percentage for the battery percentage
profile.
Code:
$capacity
This is what I use to find the temperature for the temperature profile.
Code:
$temp
Determines if phone is sleep or awake for screen state profile
Code:
$sleeping/$awake
This is the amount of power that was given towards wifi. I just upped the
amount a bit BETTER WIFI WOOHOO
Code:
/sys/module/acpuclock_arm11/parameters/pwrc_khz
/sys/module/acpuclock_arm11/parameters/wfi_khz
I/O Scheduler Tweaks:
IMO the noop scheduler is better for our read and write speeds. Simple as that.
And what more than a better scheduler for read and write speeds to go along
with the sd card speed tweaks?
Code:
echo noop > /sys/block/*/queue/scheduler
Set so that the phone's process, ram, or any other request won't get out of
order. This improves the performance because it helps our internal drive and
extral drive (if using apps2sd or data2ext or data2sd). How think of it as
organizing the request a little bit better than the default value This is more
of a being safe thing in fact, but also a little extra performance didn't hurt
anyone did it?
Code:
/sys/block/mmcblk0/queue/nr_requests
Network Tweaks:
These change the DNS server to 0.0.0.0 which in fact helped my mobile data
speeds go up by about 50-100kbps This DNS server was better than
google's or opendns (but I've always had problems with opendns). Though
google's dns server came close to being the better of the three this DNS server
was the best after being tested many times
Code:
nameserver 0.0.0.0 /etc/resolv.conf
The following are the combination of strings and values that I played with in the
beginning days of this tweak so configure our network speeds. It took about 6
hours of testing to come up with the best combination for the heroc And like
I've asked and I've said about at least 20x when asked, exactly how is our
CDMA network affected by these values when they aren't even meant for it?
They just do, now shh and enjoy your better 3G speeds But seriously ask
someone in the networking field or someone who works for sprint but is into
rooting androids (so you won't get into trouble because of hacking their data
tower speeds they give out to our herocs ). I did and it has something to do
data towers, I can't explain exactly how because once I heard that I was so
excited I just stopped listening as well
Code:
ro.ril.hsxpa=2
ro.ril.gprsclass=8
ro.ril.hep=1
ro.ril.hsdpa.category=24
ro.ril.enable.3g.prefix=1
ro.ril.htcmaskw1.bitmask=4294967295
ro.ril.htcmaskw1=14449
ro.ril.hsupa.category=3
wifi.supplicant_scan_interval=20
How frequently the keepalive probes are sent out is determined by tcp_keepalive_intvl This is value is dependent upon tcp_keepalive_probes as well, which determines how many probes are sent out. This determines the time not to kill the connection. I lowered this value so connections will be killed faster.
Code:
tcp_keepalive_intvl
tcp_keepalive_probes
Time to hold sockets, which I lowered.
Code:
tcp_fin_timeout
Socket receive buffer. Increased to increase sockets received from network.
Code:
rmem_default
Socket send buffer. Increased to increase sockets sent to the network.
Code:
wmem_default
Maximum socket receive buffer. Increased to increase the total amount of sockets we can receive from the network.
Code:
rmem_max
Maximum socket send buffer. Increased to increase the total amount of sockets we can send to the network.
Code:
wmem_max
Memory Tweaks:
This is the tweak I used to configure our internal task killer. I had to experiment
with this a lot becaue certain values made music playback very choppy when
the screen was in sleep mode. But at last these are the values I came up with
to keep our free ram high while not interfering with everyday usage too much
Code:
echo "3072,6144,9216,21000,23000,25000" > /sys/module/lowmemorykiller/parameters/minfree
SD Card Tweaks:
This is the cache of the sd card. This was set to 128 so I bumped it up to 1024. Other values may be better for your phone and it's sd card but this is the
most compatible across the board. Still a performance increase but just not the
optimal value. Why? Because all heros are different as well as that plust the sd
card everyone is using
Code:
read_ahead_kb
[/CODE]
Requirements:
- Rooted HTC Hero CDMA
- Kernel w/ Interactive, Smartass, Conservative, Powersave, Ondemand, and Performace Governors (Grab deca kernel and compile from source if not using cyanogenmod based roms, or use sobe's kernel)
ATTENTION​
DO NOT, I REPEAT, DO NOT USE SETCPU/OVERCLOCKWIDGET/COLLIN_PH/DECA'S BATTERY TWEAK, OR ANY BATTERY TWEAKING/CPU OVERLOCKING UTILITIES/SCRIPTS WITH THIS MOD!!!!!! WARNING USE THIS MOD AT YOUR OWN RISK!!! I TAKE NO RESPONSIBILITY FOR WHAT HAPPENS TO YOUR PHONE IF SOMETHING GOES WRONG! ALTHOUGH IF SOMETHING DOES HAPPEN I WILL HELP YOU AS MUCH AS POSSIBLE!!!
INSTRUCTIONS
Installing Instructions (Recovery Menu):
Difficulty: Easy
Reboot Recovery
Download and Flash Kifno's Universal HeroC Script
REMOVED UNTIL RELEASE OF V3.0.0 SOMETHINGS WERE BROKEN IN ROMS WITH THIS RELEASE.....IF YOU HAVE V2.0.1 DON'T USE IT WAIT UNTIL V3.0.0
- THANKS
Wipe cache, and dalvik-cache
Reboot into system
Enjoy
Removal Instructions (Recovery Menu):
Difficulty: Easy
Download the removal zip for latest version
Get It Here
Reboot Recovery
Flash it
Reboot
TESTED AND SUCCESSFUL ON
- Cyanogenmod 7.0.2
- NfiniteFX's Stock Rom
- LiquidSense 2.1.1
- Kifno's 2.1 Sense Roms
- Aosp Gingerbread
- GingerSense/Rock Steady
- Aosp Froyo
- CM6.1
TESTED AND SOMETIMES FAILED (BOOTLOOP/LAGGING) ON...
NOTE: If lagging with latency tweak builds, use the no latency tweak builds.
- Works on Every Rom
Change Log
Code:
4/27
- ALL BY KIFNO!!!!!!!
- Documentation for my opinion of what all my tweaks/scripts do. (I say opinion because I may or may not be correct for all of my explanations. If I am wrong please let me know, so that I can correct it so that others will not learn false information).
- setCPU, collin_ph, overclockwidget, CM7's cpu settings, or any other battery tweak/cpu overclocking utility, REPLACEMENT. This is not to be used with any of those utilities while using this or you will encounter many problems.
- mobile network and wifi speed boost ranging anywhere from 175%-400% speed gains. The percentage amount increased is determined by many other factors (the data tower in your area, your phones condition, the wifi connection, etc)
- Smoother UI
- More Free RAM
- Memory Settings Optimizer
- Any kernel tweak-er
- DroidX Market Tweak COMING SOON
- GPU Composition instead of MDP Composition
- Extended Battery Life and/or Increased Performance as a result of the tweaks and my battery tweak/cpu overclocking utility replacement script
- Tweaked the I/O
5/2
- removed some junk
- made network speeds a bit more stable
- fixed the problem were my 98kiftweaks wasn't writing the values correctly (sd card cache fix improvement & io tweaks)
- adjustments to kifCPU so that there will be longer battery life :D
- added a removal and backup script
Donations
I want everyone who is has ever donated, or has thought of donating me or anyone else to know this. XDA is a place for everyone to learn, teach, and share their work and new findings for android. Donations are not a right on XDA they are a privilege. Donations were allowed for XDA members to give and receive as a way for someone who really appreciates the original poster's work and is a way for the donor to show their thanks by doing more than pressing the thanks button. This is something that the original poster should appreciate and follow up with a PM as a thanks for their thanks, and use that as a notification, that they should keep up the good work and they're doing good things for XDA. Again recieving donations is not a right it is a privilege, that the original poster shouldn't abuse by asking for donations but instead appreciate when recieved. Asking for donations is not right and it is looked down upon on XDA because it goes against the meaning of what XDA is all about. This is something I want everyone to understand before even thinking of donating to me or anyone else or when given a donation. Don't donate because the original poster comes off as asking for money, instead if you choose to donate, donate out of showing more appreciation for another's work and as more of a way to show that you care for their work. I want everyone to understand that.
- Kifno
Credits:
unCoRrUpTeD
Made base of the script when he converted the v0.9 build.prop edits in to a script.
brainmaster
SD Card cache IDEA. I improved it.
farmatito
IDEA for I/O scheduler tweaks. I improved them for our heroes.
montalbert
MOST of the network tweaks. I just changed the values so that it'd be optimal for our heroes.
FloHimself
Screen state IDEA for kifCPU
​

Okay gonna take it for a spin and see how it works. But I have a??? Does this mod preset the max/min cpu speed??? I use jm's kernel @ 710 max 691 min. But at work or when I'm in an area that has poor reception I bump it up to 768min 806 max. Am I able to still do this and use this tweak effectively??? Also does the removal zip from your prior tweak remove this?? Also to use the battery tweaks must I do the whole calibrate thing??? The reason I ask is I use the gf's data2ext mod and letting the battery discharge is a no go.
#Root/Hack-Mod_Always*

laie1472 said:
Okay gonna take it for a spin and see how it works. But I have a??? Does this mod preset the max/min cpu speed??? I use jm's kernel @ 710 max 691 min. But at work or when I'm in an area that has poor reception I bump it up to 768min 806 max. Am I able to still do this and use this tweak effectively??? Also does the removal zip from your prior tweak remove this?? Also to use the battery tweaks must I do the whole calibrate thing??? The reason I ask is I use the gf's data2ext mod and letting the battery discharge is a no go.
#Root/Hack-Mod_Always*
Click to expand...
Click to collapse
No it doesn't remove this I need to make a removal .zip asap. But You can just take the 768mhz zip and upzip it and change the cpu values in the /system/bin/kifCPU.sh file
just look for the the lines that effect the cpu speeds. If you don't know which ones do, then read my explanation for my tweaks
OH YEAH EVERYONE I ADDED MY EXPLANATION FOR TWEAKS If I am wrong about anything please, tell me asap so I can update it so people don't learn false information.
Glad to be on a fresh start with this

I'm gonna be all over this. Haha.

Please post feedback as to hours of battery life increase based on your normal usage and which build worked for you rom. Please post your rom and kernel you're using as well. and any other things you'd like for me to know as well. Thanks

flashing on aospCmod now (right after this nandroid finishes)

Haha. Outstanding!
Rom: CyanogenMod 7.0.2
Kif's Universal Script: Latency 768
Kernel: Sobe's AP5
Battery: Will post feed back when I get off work.
Network speed: Outstanding on my phone!
Keyboard response: before kid's tweak, laggy After kif's tweak, VERY! responsive.
UI: Speedy!
Haha. Feels like I just bought a new phone.
I can't wait to test this out on Rock Steady when I get home! Honestly I flash this on work hours. Ha. Yea I'm a flash freak like everyone else. I should just say I'm sick *cough cough* ha.
Outstanding work bro!
Will post more feedbacks when I get home.
Take care and God Bless.

I'm using one of Zen's kernels (710MHz)on NfiniteFX ROM. Can I use this? I'm not sure Zen's kernels have the governors you mention. Where can I get such a kernel, remembering that I am running Sense. I've read Zen kernels are usually best for Sense.
Thanks!

so far so good installed fine
downloads 35-50% faster on average on a few trials via 3g.

In regard to your explanation:
Code:
/sys/block/mmcblk1/queue/nr_requests
As stated previously in the old thread, this file has never and will never exist on the hero, because we only have one SD device.
This DNS server [0.0.0.0] was better than
google's or opendns (but I've always had problems with opendns)
Click to expand...
Click to collapse
0.0.0.0 is NOT a DNS. All this value does is force the phone to use whichever DNS the network specifies (which it may or may not be doing anyway).
Code:
ro.ril.hsxpa=2
ro.ril.gprsclass=8
ro.ril.hep=1
ro.ril.enable.dtm=1
ro.ril.hsdpa.category=24
ro.ril.enable.a53=1
ro.ril.enable.3g.prefix=1
ro.ril.htcmaskw1.bitmask=4294967295
ro.ril.htcmaskw1=14449
ro.ril.hsupa.category=3
You said to "ask someone in the networking field" about these values. Someone from the "networking field" (dhero) already chimed in (as did several other people) and told you that some of these lines don't even do anything. The only thing here that's probably making a difference in network speeds is the bitmask value (which is just setting all bits to 1, negating what they actually do).
For instance, I can tell you 100%, for a fact, that the "ro.ril.enable.dtm" line does nothing on the hero, because the entire point of this line is to enable simultaneous use of voice/data on GSM networks. CDMA networks have never been able to do this, and that's not something you can change
The line "ro.ril.enable.a53" also does absolutely nothing on our phones. A5/3 is an encryption algorithm, used on GSM networks. It has no use in CDMA devices, and was actually broken by hackers in recent history.
I've love to see some real documentation of how setting these values really makes a difference. The facts of speed tests are that (1) they are only testing your "burst" speeds which means they don't really answer many questions about long-term performance and that (2) they can vary wildly in the same time frame. I know that I have personally always had better EV-DO speeds than your scripts supposedly provide (sustained average 1.5-2mb/s downstream), and that all depends on signal range and nearby devices.
Right now I'm working on actually reverse-engineering the HTC RIL library to see what these values REALLY change. As far as I can tell, some of them never actually make a difference on the CDMA Hero and are just left over from the GSM Hero and other devices. They are read in from the prop file, but the variables which contain them aren't referenced by the CDMA code paths.
Code:
windowsmgr.max_events_per_sec=60
As stated previously in the old thread, this value does nothing because that's already the default value in the source code.
Code:
keyguard.no_require_sim=true
As stated previously in the old thread, this is already set in the build props.
Code:
debug.sf.hw=1
As stated previously in the old thread (and backed up by PROVIDING THE SOURCE CODE), this line does nothing because it's the equivalent of not specifying it at all. This is why we removed it from the CM build a LONG time ago. The ONLY time this line would EVER make a difference is if someone had deliberately set it to 0 beforehand, and as far as I know, no ROM (including the stock one) has ever shipped with 0 set.
The DEFAULT behavior of SurfaceFlinger is to always use the GPU when possible. The ONLY reason the "debug.sf.hw" line exists is for troubleshooting/debugging, for example when booting the emulator.
------------------------------------------
In regard to my own exploration of the zips provided (for reference I used the no-latency 691 zip):
You have a typo in your code.
Code:
CHECK_NOOP=` cat /sys/block/mtdblock3/queue/scheduler
The tailing backtick is missing.
Why are you providing busybox in your zip? The version you provide (1.15) is outdated; a newer version is already in CM7 and other ROM images. And the folder you're copying it to (system/sbin) doesn't actually exist.
By overwriting the init.local.rc script instead of appending your code to it, you are effectively breaking compcache in CM.
Your CPU profiles contain multiple infinite loops. This is bad practice. Your loops don't contain ANY sleep calls as far as I can tell, which means they run indefinitely, sucking up CPU cycles and battery. Your script should be sleeping on an interval.
The functions called by your infinite loop themselves contain infinite loops, which means that (as far as I can tell) they will never return and charging source changes will never be detected. Am I reading this wrong? Does this really work?

Blah blah blah..
Your scripts are working fine on my phone and others even though you've missed a few things here and there. The main thing is that your trying and trying leads to something even better. Looking forward to seeing v2.x and further.

I feel like I am on a creepy merry-go-round.....
Yet again kifno, when you could be an asset to the community simply by giving proper credits originally and saying that you used others work and made it better, you take all or most of the credit for yourself. If you want to help the community, do so by following the rules and common sense. FYI you cant "improve" brainmasters sd tweak because ALL it does is change the read_ahead_kb in sys/devices/virtual/bdi/179:0/read_ahead_kb. Now here's some links that users/mods/kifno would do well to pay attention to the dates of, these are also the only ones that I personally have reviewed recently, I would bet there are more:
http://andrs.w3pla.net/autokiller/kernel
http://forum.xda-developers.com/showthread.php?t=813309
http://forum.xda-developers.com/showpost.php?p=11496754
http://forum.xda-developers.com/showthread.php?t=991276
Quite obviously this is not kifno's "original" work or ideas, or even code. After all it was recently noted in here that there is code for GSM devices. Why would that be in a script for a CDMA phone, unless of course the code was kanged. I just wish that if work was to be shared, it ought to be done so properly and not with this "MY WORK THIS TIME I SWEAR SILLY" bull.
I sent kifno a PM earlier tonight about this VERY thread when the OP only had credited uncorrupted. I told him to fix the lies about "all mine" and he did somewhat, but not fully as you all can see. My point is that this kind of action on my part SHOULD be unnecessary, but it seems to continue to be in ALL the threads kifno makes. Users, I know lots of this works but that's not the point. It is taken, and unabashedly handed out as original work, which it is not. That is why I continue to post relevant info when it it obvious. It is NOT to incite war, only to pay respect to the actual devs who created these works, which kifno does not seem to want to do.
I'm Pretty sure that the definition of kanging is taking others work without askance or credit - which is what this is. It's actually OK and encouraged to use others work in this community, that way we all get better tweaks and a better knowledge and a better user experience. BUT this is only OK if done following forum rules - which stem from mutual respect and community enrichment.
I am convinced the response will be "BUT BUT I DIDN'T COPY, I MADE THESE MYSELF", to which my response would be "yeah right".
Have a beautiful night/day ladies and gents. I have said my piece...

Let's try to stick to constructive criticism and not resort to personal attacks. It's killing the forum.

il Duce said:
I feel like I am on a creepy merry-go-round.....
Yet again kifno, when you could be an asset to the community simply by giving proper credits originally and saying that you used others work and made it better, you take all or most of the credit for yourself. If you want to help the community, do so by following the rules and common sense. FYI you cant "improve" brainmasters sd tweak because ALL it does is change the read_ahead_kb in sys/devices/virtual/bdi/179:0/read_ahead_kb. Now here's some links that users/mods/kifno would do well to pay attention to the dates of, these are also the only ones that I personally have reviewed recently, I would bet there are more:
http://andrs.w3pla.net/autokiller/kernel
http://forum.xda-developers.com/showthread.php?t=813309
http://forum.xda-developers.com/showpost.php?p=11496754
http://forum.xda-developers.com/showthread.php?t=991276
Quite obviously this is not kifno's "original" work or ideas, or even code. After all it was recently noted in here that there is code for GSM devices. Why would that be in a script for a CDMA phone, unless of course the code was kanged. I just wish that if work was to be shared, it ought to be done so properly and not with this "MY WORK THIS TIME I SWEAR SILLY" bull.
I sent kifno a PM earlier tonight about this VERY thread when the OP only had credited uncorrupted. I told him to fix the lies about "all mine" and he did somewhat, but not fully as you all can see. My point is that this kind of action on my part SHOULD be unnecessary, but it seems to continue to be in ALL the threads kifno makes. Users, I know lots of this works but that's not the point. It is taken, and unabashedly handed out as original work, which it is not. That is why I continue to post relevant info when it it obvious. It is NOT to incite war, only to pay respect to the actual devs who created these works, which kifno does not seem to want to do.
I'm Pretty sure that the definition of kanging is taking others work without askance or credit - which is what this is. It's actually OK and encouraged to use others work in this community, that way we all get better tweaks and a better knowledge and a better user experience. BUT this is only OK if done following forum rules - which stem from mutual respect and community enrichment.
I am convinced the response will be "BUT BUT I DIDN'T COPY, I MADE THESE MYSELF", to which my response would be "yeah right".
Have a beautiful night/day ladies and gents. I have said my piece...
Click to expand...
Click to collapse
After reading this, i agree with u. Kifno should credit more people for most of the things on here. All he did was compile it all together. Am i saying that right?

Ok flash on the sense rom didn't really do so well phone froze 3 times on the market took battery out then froze on whit HTC screen so I tried it cm7.2 and works like a charm
Sent from my HERO200 using XDA App

kifno said:
No it doesn't remove this I need to make a removal .zip asap. But You can just take the 768mhz zip and upzip it and change the cpu values in the /system/bin/kifCPU.sh file
just look for the the lines that effect the cpu speeds. If you don't know which ones do, then read my explanation for my tweaks
OH YEAH EVERYONE I ADDED MY EXPLANATION FOR TWEAKS If I am wrong about anything please, tell me asap so I can update it so people don't learn false information.
Glad to be on a fresh start with this
Click to expand...
Click to collapse
Humm well didn't really wanna go that far into your script. Is there anyway if you have some time free you could possibly edit the 768 scripts for me and post or send them threw pm??? I wouldn't mine running your mods and posting feed back I just don't want to change my daily kernel. Ill hold off on flashing this untill I hear from you. Thanks.
#Root/Hack-Mod_Always*

bravo1565 said:
Ok flash on the sense rom didn't really do so well phone froze 3 times on the market took battery out then froze on whit HTC screen so I tried it cm7.2 and works like a charm
Sent from my HERO200 using XDA App
Click to expand...
Click to collapse
Do you use kifnos sense rom or espresso? I flashed the latency 768 tweak on his espresso 2.1 rom and everythings running flawlessly. I flashed the tweak on a full battery so I'll be back when the phone dies to report my battery life and performance.

jasonmaloney said:
In regard to your explanation:
Code:
/sys/block/mmcblk1/queue/nr_requests
As stated previously in the old thread, this file has never and will never exist on the hero, because we only have one SD device.
Click to expand...
Click to collapse
So we don't have the the mmcblck1 partition? Hmp I know what I'll do to fix m y nr_request tweak then I'll add it to the loop that checks for all values in the mmc* blocks Checked it and it already is I need to edit my reasons for the tweaks lol. So no worries this value is only changed in all mmc blocks that exsist.
jasonmaloney said:
0.0.0.0 is NOT a DNS. All this value does is force the phone to use whichever DNS the network specifies (which it may or may not be doing anyway).
Code:
ro.ril.hsxpa=2
ro.ril.gprsclass=8
ro.ril.hep=1
ro.ril.enable.dtm=1
ro.ril.hsdpa.category=24
ro.ril.enable.a53=1
ro.ril.enable.3g.prefix=1
ro.ril.htcmaskw1.bitmask=4294967295
ro.ril.htcmaskw1=14449
ro.ril.hsupa.category=3
You said to "ask someone in the networking field" about these values. Someone from the "networking field" (dhero) already chimed in (as did several other people) and told you that some of these lines don't even do anything. The only thing here that's probably making a difference in network speeds is the bitmask value (which is just setting all bits to 1, negating what they actually do).
For instance, I can tell you 100%, for a fact, that the "ro.ril.enable.dtm" line does nothing on the hero, because the entire point of this line is to enable simultaneous use of voice/data on GSM networks. CDMA networks have never been able to do this, and that's not something you can change.
The line "ro.ril.enable.a53" also does absolutely nothing on our phones. A5/3 is an encryption algorithm, used on GSM networks. It has no use in CDMA devices, and was actually broken by hackers in recent history.
Click to expand...
Click to collapse
Oh wee thanks jason The lines you said to remove, and a few more lines have been removed from the network tweak, for next release, because only a few are making the real difference which I have tested.
jasonmaloney said:
I've love to see some real documentation of how setting these values really makes a difference. The facts of speed tests are that (1) they are only testing your "burst" speeds which means they don't really answer many questions about long-term performance and that (2) they can vary wildly in the same time frame. I know that I have personally always had better EV-DO speeds than your scripts supposedly provide (sustained average 1.5-2mb/s downstream), and that all depends on signal range and nearby devices.
Right now I'm working on actually reverse-engineering the HTC RIL library to see what these values REALLY change. As far as I can tell, some of them never actually make a difference on the CDMA Hero and are just left over from the GSM Hero and other devices. They are read in from the prop file, but the variables which contain them aren't referenced by the CDMA code paths.
Click to expand...
Click to collapse
If you could figure out exactly what they change (as far as I know its just general speed) that would be better for the first post's explanation of them. I'm going based of the fact that when I changed a few of the strings values, it slowed the network down, and certain values speed it up.
jasonmaloney said:
Code:
windowsmgr.max_events_per_sec=60
As stated previously in the old thread, this value does nothing because that's already the default value in the source code.
Code:
keyguard.no_require_sim=true
As stated previously in the old thread, this is already set in the build props.
Click to expand...
Click to collapse
Both removed already last night
jasonmaloney said:
Code:
debug.sf.hw=1
As stated previously in the old thread (and backed up by PROVIDING THE SOURCE CODE), this line does nothing because it's the equivalent of not specifying it at all. This is why we removed it from the CM build a LONG time ago. The ONLY time this line would EVER make a difference is if someone had deliberately set it to 0 beforehand, and as far as I know, no ROM (including the stock one) has ever shipped with 0 set.
The DEFAULT behavior of SurfaceFlinger is to always use the GPU when possible. The ONLY reason the "debug.sf.hw" line exists is for troubleshooting/debugging, for example when booting the emulator.
Click to expand...
Click to collapse
This is one that wasn't removed last night but will be I didn't know that it wasn't set to 0 because it wasn't specified in any roms I looked at. Thanks for that info
jasonmaloney said:
In regard to my own exploration of the zips provided (for reference I used the no-latency 691 zip):
You have a typo in your code.
Code:
CHECK_NOOP=` cat /sys/block/mtdblock3/queue/scheduler
The tailing backtick is missing.
Click to expand...
Click to collapse
I hate making those minor mistakes thanks for catching that jason
jasonmaloney said:
Why are you providing busybox in your zip? The version you provide (1.15) is outdated; a newer version is already in CM7 and other ROM images. And the folder you're copying it to (system/sbin) doesn't actually exist.
Click to expand...
Click to collapse
From what uncorrupted told me, in a way it is better than the busybox in most roms. I'll ask him about it, but until he provides reasons why, I'll remove it.
jasonmaloney said:
By overwriting the init.local.rc script instead of appending your code to it, you are effectively breaking compcache in CM.
Click to expand...
Click to collapse
Saw that myself when I looked at CM7's init.local.rc. It breaks that and any other service set in the init.local.rc. WHICH IS NOT GOOD.
jasonmaloney said:
Your CPU profiles contain multiple infinite loops. This is bad practice. Your loops don't contain ANY sleep calls as far as I can tell, which means they run indefinitely, sucking up CPU cycles and battery. Your script should be sleeping on an interval.
Click to expand...
Click to collapse
I'll have it sleep every second or so because I doubt anyone is running their phone straight for hours and hours without letting it sleep. So adding a sleep interval will help with the should help with the battery life portion of this tweak as well
I had a sleep interval back in the v1.x series which helped the battery life, in my other infinite scripts, I need to add that again
jasonmaloney said:
The functions called by your infinite loop themselves contain infinite loops, which means that (as far as I can tell) they will never return and charging source changes will never be detected. Am I reading this wrong? Does this really work?
Click to expand...
Click to collapse
Oh yes Do you know what a until loop is? It basically saying the temperature drops it will cap the cpu speed. Once the temperature isn't high anymore then it uncaps the cpu speed again So this is to keep your phone from getting too hot, I know my phone does Also since the cpu is being capped this would result in the battery temperature going down and therefore once the temp is lowered it returns to the battery charging source changes. So yes it does work

il Duce said:
I feel like I am on a creepy merry-go-round.....
Yet again kifno, when you could be an asset to the community simply by giving proper credits originally and saying that you used others work and made it better, you take all or most of the credit for yourself. If you want to help the community, do so by following the rules and common sense. FYI you cant "improve" brainmasters sd tweak because ALL it does is change the read_ahead_kb in sys/devices/virtual/bdi/179:0/read_ahead_kb.
Click to expand...
Click to collapse
I did improve his tweak, so there you are wrong sir. I will be sending him a message about if he changed the value for all the bdi's sub-directories read_ahead_kb he would in fact improve his sd tweak. He sets it for just the 179:0 but when I changed it to set it for changing all the bdi's sub-directories read_ahead_kb my sd card performance was much better, than just his tweak which just made it better.
il Duce said:
Now here's some links that users/mods/kifno would do well to pay attention to the dates of, these are also the only ones that I personally have reviewed recently, I would bet there are more:
http://andrs.w3pla.net/autokiller/kernel
http://forum.xda-developers.com/showthread.php?t=813309
http://forum.xda-developers.com/showpost.php?p=11496754
http://forum.xda-developers.com/showthread.php?t=991276
Click to expand...
Click to collapse
The one's who I ORIGIANALLY got the ideas from are credited. Anyone who is not credited I did not get any ideas from. If a person isn't allowed to use their knowledge of linux operating system's files and how they tweak linux and use them on android then that just isn't right. I've been on linux for years and you're saying that the tweaks I used for my linux system I can't change the values and use on the heroc, come on now. That isn't fair.
il Duce said:
Quite obviously this is not kifno's "original" work or ideas, or even code. After all it was recently noted in here that there is code for GSM devices. Why would that be in a script for a CDMA phone, unless of course the code was kanged. I just wish that if work was to be shared, it ought to be done so properly and not with this "MY WORK THIS TIME I SWEAR SILLY" bull.
I sent kifno a PM earlier tonight about this VERY thread when the OP only had credited uncorrupted. I told him to fix the lies about "all mine" and he did somewhat, but not fully as you all can see. My point is that this kind of action on my part SHOULD be unnecessary, but it seems to continue to be in ALL the threads kifno makes. Users, I know lots of this works but that's not the point. It is taken, and unabashedly handed out as original work, which it is not. That is why I continue to post relevant info when it it obvious. It is NOT to incite war, only to pay respect to the actual devs who created these works, which kifno does not seem to want to do.
I'm Pretty sure that the definition of kanging is taking others work without askance or credit - which is what this is. It's actually OK and encouraged to use others work in this community, that way we all get better tweaks and a better knowledge and a better user experience. BUT this is only OK if done following forum rules - which stem from mutual respect and community enrichment.
I am convinced the response will be "BUT BUT I DIDN'T COPY, I MADE THESE MYSELF", to which my response would be "yeah right".
Have a beautiful night/day ladies and gents. I have said my piece...
Click to expand...
Click to collapse
The response you are "convinced" will be, is not the response I am giving you. The people whose ideas I were using and made better were back from the 0.x series (which is long ago). Also as for the code not even being mine? THE MAJORITY OF IT IS MINE. I used the screen state idea and built off of it to make a full out, cpu/batter tweak utility replacement. My next step is to make a menu for the users to change those values themselves. The users whose ideas I have used AND IMPROVED ON, have been credited as we talked about, I just had to backtrack who I really got the ideas from and not others who used their ideas as well as myself. Everything else I have done, and came up with myself. Believe it or not. Use linux for a few years on a sucky laptop and I bet you'll be wanted to tweak it, too. Which is how I learned so much about linux's files, which I quickly found android to be almost like a "portable linux" operating system One of the reasons I got the phone. Have a beautiful day ladies and gents
"kif'd"
- Kifno

XGodOfModzX said:
After reading this, i agree with u. Kifno should credit more people for most of the things on here. All he did was compile it all together. Am i saying that right?
Click to expand...
Click to collapse
Read my post, i used IDEAS and made them better. The one thing I did use and compile into the tweak was the network build.prop tweaks. Which some of the strings do nothing. Be on the look out for v2.0.1 also the credits that are there now are for v2.0.1 which will be released tonight. Minor changes made but they're for the better.

Milkdrop/androp amazing music visualization live wallpaper

AerialX said:
Alright, thanks for the results everyone. I asked because I wanted to decide which framebuffer method would be selected as the default... I decided on the "slow" version - 8bdefb7e - as it's the most compatible option. The "fast" version can be chosen as a preference for those who prefer the speed. It may not work on all devices, and seems to produce artifacts and some tearing, though it probably is preferable for most simply due to the speed.
So, here you go, latest version: Download
Built for ARM and ARMv7, does not include the NEON extensions. You may want to uninstall the old one before installing this.
EDIT: Fine, have a NEON build too: Download
Hint: the main change is the inclusion of settings. I consider this build to be very close to the initial release for the application on the Android Market. Just a few things remain...
What's Left
In order of priority...
Filtering of non-white-screen presets. The app will include the projectM preset library by default, excluding any that just result in a white screen. I don't believe I will be able to distribute any of the Winamp/MilkDrop library itself, as awesome as it is.
Stability enhancements. It's probably still somewhat crashy. I'm not sure how much, though. I'd love to get some detailed reports on how stable/crashy it is for you guys.
snoop() support, otherwise the wallpaper requires 2.3... I don't have anything older though. Would anyone be able to test on an older OS for me if I supplied a build?
x86 support. Means writing a few missing STL pieces.
NEON detection, and the loading of an appropriate optimized library. I get the feeling that this is just a placebo, but will try to get it in.
Optimizations. Would be nice if it didn't essentially restart every time you visit your home screen. I'm probably leaving this for a 1.1 release though.
Localizations. If anyone wants to help translate the settings page into their native tongue, I'll happily include them.
Anything else I forgot...
What I Need
It would be great if anyone who tries it can comment on its stability. Whether it often dies, reverts to some other wallpaper, completely kills your system, or whatever. Just give me your overall experience with the wallpaper. I'm not necessarily interested in hearing about its performance at this point - if it runs slowly on your phone, I suggest switching to the "fast" render method and only using presets that run speedily. Of course, miscellaneous suggestions / comments / criticism are welcome as well!
Another thing I was hoping someone could do is go through all the presets and filter out the bad "white" ones. The new settings page makes it easy to test a single preset at will. So if anyone is willing to do this, I could really use two zips: one containing all working presets from the projectM set, one containing all from the MilkDrop set.
As a base for the projectM set, please use this: Download
For the base MilkDrop set, find the attachment from a few pages ago.
You may also want to note any that run particularly slow, but please don't exclude them from these packages.
EDIT: As a test, feel free to try the exact same preset on both the non-NEON and NEON builds and see if there's any noticeable improvement there.
Click to expand...
Click to collapse
Hands down best app ever
Sent from my LG-P999 using XDA App

Any screenshots?

Um seems to be a few post missing in this thread... Usually when something starts like this:
Alright, thanks for the results everyone. I asked because I wanted to decide which framebuffer method would be selected as the default...
Click to expand...
Click to collapse
What results are we talking about here? What is this exactly? Kinda like writing a book that starts:
But when the baby came out looking like death on a hot tin roof, Jim finally found the nerve to call her out and say, "Devil wench, I will not accept that thing as my my spawn! I know you have been sleeping with your brother!"

Porting Chromium to Windows RT

So, I've been at this for about 48 hours now (not continuously, but closer than you might think) and I figured I should take a break from modifying project files and puzzling over alignment issues to discuss the project, share some of the problems I've been having and ask if anybody can help, and so on.
The general idea is "Chromium build for Windows (on x86/x64) and build on ARM (for Linux), so there must be a way to build it for Windows on ARM". For the most part, that even looks like it's true. Probably at least 80% of 654 Visual Studio projects (no, that's not a joke) either build just fine with only minor amounts of work, or are things that we don't actually need (I'll try building the test suites... once everything else builds!!)
Areas that have given me problems (caution: some chance of brief rants ahead):
v8. Less than you might think, though. Setting the flags for Arm seems to have been enough.
Sandbox. There's a fair bit of thunking coded in assembly going on in the sandbox for x86. Not sure what's up with it (I don't know exactly how the Chromium sandbox works) but it'll have to come out or be replaced. The Linux (including ARM) sandbox seems to be SELinux-based, which doesn't help at all.
Native Client (NaCl). I think all the assembly is in test code, though, so I may just boldly #ifdef if all away.
libjpg-turbo (libjpg). Piles of carefully optimized assembly... for x86 and x64. There is a set of ARM assembly (for Linux) that Visual Studio won't compile, but something else might... or I may tweak until it works. Of course, I could also just accept the speed hit and use the version of libjpg implemented in nice, portable C.
Anything where the developers tried to use some SSE to speed things up. I may be able to replace it with NEON code, or I may just remove it and hope **** doesn't break. We'll see.
Inline assembly in general. Even when it's ARM assembly, Visual Studio / CL.exe don't want anything to do with it (__asm is apparently now an invalid keyword). I suspect I'll have to just pull the assembly out into stand-alone functions in their own files, then compile them to object files and link them back in later. If I can figure out the best way to do this (for example, I'll want to inline the asm functions) then it shouldn't impact performance. Seriously though, I kind of hate inline assembly. I can read assembly just fine, but I'm usually staring at it in a debugger or disassembly tool, not in the middle of source code I'm trying to build...
Everywhere that the current state of the CPU is cared about (exception and crash handlers, in particular) because the CONTEXT structure is, of course, CPU-specific. They're pretty easy to get past, though.
Low-level functions, like MemoryBarrier. Fortunately, it's implemented in ntdll.h... but as a macro, which breaks at least half the places it's referenced. Solution: where it breaks things, undefine the macro and just have it be an inline function that does what the macro did.
Running out of memory. Not even joking... well, OK, a little bit. I've got 32GB; I won't actually run out. Both Visual Studio and cl.exe do at times, though!. Task Manager says VS is currently using 1,928 MB, and before I restarted it, it broke 2.5GB private working set. Pretty good for a program that for some reason is still 32-bit...
Goddamn compiler flags. Seriously, every single project (I mentioned there are over 600, right?) has its LIBPATHs hardcoded to point at x86. Several projects have /D:_X86_ or similar (that's supposed to be set by the build tools, not the user, you idiots...) which plays merry hell with the #ifdef guards. Everything has /SAFESEH specified, not in the actual property table where the IDE could have removed it (unneeded and invlaid on ARM) but in the "extra stuff we'll pass on the build command line" field, which means every single .EXE/.DLL project must be modified or the linker will fail.
My current biggest goal is the JPG library; nobody wants to use a browser without it. After that, I'll tackle the sandbox, leaving NaCl for last... well, last before whatever else crops up.
Anyhow, thoughts/comments/advice are welcome... in the mean time, I'm going to go eat something (for the first time in ~22 hours) and then get some sleep.

Kudos for having the patience to look though this monster.
It's my understanding that NaCl is still a pretty niche thing at the moment. Is it possible to easily either disable it or completely hack it out, or do other more critical parts of Chromium now depend on it?

I don't think anything truly depends on it. I'll look in the VS dependency hierarchy and see how many things list it, and how awful it would be to remove them.. after I get the other stuff working. I may pass on the sandbox as well, if possible; it makes the security guy in me cringe something awful, but as they say, shipping is a feature..

great

Please make that happen !

Working on it! I've gotten over half of the projects to build and link, but some other stuff is adamantly refusing to work. I'm beginning to suspect I'll need to work from the other direction - rather than starting at the bottom and building all the dependencies, then combining them into browser components, and then eventually combining all the components into a complete piece of software, I may have to work from the top, removing components until the whole thing builds (at which point it will likely be useless, or all-but) and then seeing what I can add back in. I thought it would be faster to just assume everything can be made to work and only exclude something if it proved intractable, but at this point I've got a ton of very small components and almost no ability to combine them.
It would also help if VS was better at managing such truly immense tasks. For example, I have no simple graph of what all is and is not building, so I'm being forced to manually map that onto the VS dependency tree and see what is blocking a given component from building successfully, and how much is dependent upon it, one erroring project at a time (and there are a *lot* of erroring projects - my last attempt to build any substantial part of the system saw 50 of 400 projects fail).

GoodDayToDie said:
Working on it! I've gotten over half of the projects to build and link, but some other stuff is adamantly refusing to work. I'm beginning to suspect I'll need to work from the other direction - rather than starting at the bottom and building all the dependencies, then combining them into browser components, and then eventually combining all the components into a complete piece of software, I may have to work from the top, removing components until the whole thing builds (at which point it will likely be useless, or all-but) and then seeing what I can add back in. I thought it would be faster to just assume everything can be made to work and only exclude something if it proved intractable, but at this point I've got a ton of very small components and almost no ability to combine them.
It would also help if VS was better at managing such truly immense tasks. For example, I have no simple graph of what all is and is not building, so I'm being forced to manually map that onto the VS dependency tree and see what is blocking a given component from building successfully, and how much is dependent upon it, one erroring project at a time (and there are a *lot* of erroring projects - my last attempt to build any substantial part of the system saw 50 of 400 projects fail).
Click to expand...
Click to collapse
I thinkt tht is a mutch better taktic and mutch less frustrading.
I would love to see just a minimal version of it. After that all the small componens can follow.
50 of 400 is pretty good i think. Better then i expected

Bear in mind that the entire thing is 650 projects. If 50 fail at that level, many of the higher-level ones (dependent upon the lower-level) will fail too. I'll see what I can do. I may or may not be able to get v8 actually working (without it, the JS speed will be very bad, think IE8 at best) and I may have to fall back to the legacy libjpeg (which will cut JPEG render speeds by at least a factor of 2). Skia (2D drawing library used by Chrome) has a bunch of assembly optimizations that I need to get it to use the Arm version of instead. There's a couple of total hacks with the library files I've had to pull, which may or may not result in a working final build. We'll see.

GoodDayToDie said:
Bear in mind that the entire thing is 650 projects. If 50 fail at that level, many of the higher-level ones (dependent upon the lower-level) will fail too. I'll see what I can do. I may or may not be able to get v8 actually working (without it, the JS speed will be very bad, think IE8 at best) and I may have to fall back to the legacy libjpeg (which will cut JPEG render speeds by at least a factor of 2). Skia (2D drawing library used by Chrome) has a bunch of assembly optimizations that I need to get it to use the Arm version of instead. There's a couple of total hacks with the library files I've had to pull, which may or may not result in a working final build. We'll see.
Click to expand...
Click to collapse
the v8 engine ( used in nodejs ) has been ported to ARM :
I still can't link : htt p://ww w.it-wars.com/article305/compiler-node-js-pour-arm-v5
perhaps it will help you
Edit : oups, I just see that another great user of this forum made the port of nodejs to RT

Yep... but they did it without v8. That's not an encouraging result, but I feel like I'm so close...

Is there a GitHub repo so we can help or track the progress of the project ?

Sorry, not at present. There probably should be. The sheer size of the codebase is incredible (about 2.4GB) and having some way to share it practically would be good.
Also, I suspect this would go a lot faster if I don't have to repeat the work of others. I know that there's a working Webkit DLL out there, for example (though with several features, including the V8 JS engine, missing) and if I could get my hands on that it would drastically reduce the number of additional components I need to build. Currently I'm working on the sandbux, but expect that I will need to rip the whole thing out and basically have the browser run as though it was always passed the --no-sandbox parameter, at least for the first build. Too damn much assembly.

http://www.engadget.com/2013/01/22/google-chrome-native-client-arm-support/
This wouldn't have any impact on this project, would it?
Sent from my SCH-I535 using xda-developers app, complete with annoying signatures.

It probably means that NaCl on Windows RT will be possible in the future. At present, I'm cutting it out of the build - too much x86-specific stuff there to port it over myself, and it owuldn't be able to run x86-compiled NaCl code anyhow.

You might have bit off more than you could chew. It'd better if you put your current progress under version control on some public site so that other people may be able to help you.
It's a big and complex project. You are taking a lot of time, and understandably so. But just open up to other people and you could get this done faster.

Yeah, this is probably true. My life also got unexpectedly *busy* in the last week; a couple weeks ago I had many times as much free time as I do now, and so porting has slowed down.
My upload speed would take ages (literally probably at least a day of solid activity; it's embarassingly slow) to push the full source anywhere, but I may make the effort anyhow. I'll have to post it somewhere for GPL compliance in any case...

You may upload only the diff files, they'll probably be smaller then the whole distribution.

Not to pour cold water on you however, IE10 is already faster than the latest Chrome build in Windows Phone, Windows 8.
I don't see the point of this.
I have personally jumped from IE8 > FF > Chrome and finally back to IE10 over the years depends on its usability, smoothness, speed, etc

Speed isn't the only reason to use a browser. I actually prefer IE myself, but there are some things that other browsers do better than it (in the case of Chrome, parts of HTML5, the syncing across Google services, etc.) Also, Chrome gets updated far more often than IE; IE9 was equal with Chrome on speed at its release, and was far behind by the time IE10 came out.
The reason for this project, though, is a mixture of interest in what it takes, and a desire to benefit the community. Microsoft has deeped that only software which they have blessed may run on the Windows RT desktop. I disagree, and have chosen (among several other things) to port a web browser because I feel that it's important for users to have choice.

LastBattle said:
Not to pour cold water on you however, IE10 is already faster than the latest Chrome build in Windows Phone, Windows 8.
I don't see the point of this.
Click to expand...
Click to collapse
Some websites do not get along with the trident rendering engine. Some webdevs are so "Oh f*** IE I don't care" and block access to features just because it is IE. I have experienced this first hand on IE10 on my surface where it tells me to come back when I have a decent browser, only to not have the choice to do that.
This really isn't the webdevs fault either, for years IE was the scum of the internet, only recently has IE caught up to the rest of the browsers (and in my opinion exceeded some) but the years of IE being bad have left a lot of disjointed webdevs who won't even consider giving the latest IE a chance.