[Q] Team EOS: User control of regulatory domain. - Xoom Q&A, Help & Troubleshooting

[Q] Team EOS: User control of regulatory domain. - Xoom Q&A, Help & Troubleshooting

Hi all
I have a xoom and installed eos about 30 mins after opening the box.
I love it but no user control of regulatory domain, that sucks.
Any pointers on how to implement this, build.prop keys don't seem to work and i'd not want to have to recompile gpu/oc kernel, but would if necessary.
It would seem that cm has it but don't want to move from eos as its ace.

Well it depends on what aspect of regulatory domain you speak of. Regarding wifi channels, yes its in the kernel. I have a patch that eliminates all the regulatory crap. This is something we are still debating as to whether we should implement or not.

9Yes wifi, i understand your concerns over implementing such a patch. But also believe that full control over our own device is fair and our own responsibility, Not to placed on the shoulders of dev's like you who do all the work so we can all enjoy our kit.
I am on nightly so would that mean it's in this kernel? If so should would i need something like iw to set it or a key in build.prop?
Thanks.

No iw won't help if its not enabled in the kernel. Ill likely add this to my overlay anyway so no worries.

Nice one
While your talking about overlay, when i'v flashed it i'v noticed that the gpu was not clocked
With the new kernel, any chance of a gpu version of the overlay, I know its not a mega overclock but would still prefer it in there call me cheeky if you want lol.

Sorry man, gpuoc in the overlay kernel ain't happening. I've merged a regulatory remove patch. However, I'm prettty sure we have to mod the firmware calibration file as well. Ill talk with the team about a more comprehensive solution.

No worries about gpu, its not that big of deal. Thanks for the merge i appreciate it.
Keep up the good work.
Thanks.

Just wondering if you managed to talk to the team about implementing this as a feature?

Related

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.

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.

[Q] Some information about sec.ko ???

Hi kernel hackers,
it is getting very silent recently about possible security hacks on the Milestone platform.
Today i stumbled over some kernel code located in /drivers/misc/sec.
Maybe this had been discussed already.... anyway
There're some interesting functions in the source code and i wonder which application is using this module to enter the secure world of OMAP.
Some of the functions are accessing registers, that are also involved in low level routines of the bootcode (e.g. mbmloader).
Some questions:
Which application in android userspace is using this module?
Could we tweak this module to get access to some of the protected OMAP registers?
Is it a signed module?
Would be nice to use a modified module and activate some of the blocked features (e.g. DAP controller for debugging).
Any comments welcome!!!
Regards,
scholbert

scholbert said:
Hi kernel hackers,
it is getting very silent recently about possible security hacks on the Milestone platform.
Today i stumbled over some kernel code located in /drivers/misc/sec.
Maybe this had been discussed already.... anyway
There're some interesting functions in the source code and i wonder which application is using this module to enter the secure world of OMAP.
Some of the functions are accessing registers, that are also involved in low level routines of the bootcode (e.g. mbmloader).
Some questions:
Which application in android userspace is using this module?
Could we tweak this module to get access to some of the protected OMAP registers?
Is it a signed module?
Would be nice to use a modified module and activate some of the blocked features (e.g. DAP controller for debugging).
Any comments welcome!!!
Regards,
scholbert
Click to expand...
Click to collapse
Well, I'm not a kernel hacker, but I have an educated guess...
I believe that the radio system uses those functions to check whether the kernel is valid or not, so, we have the radio not working with a replacement kernel that is loaded using kexec...
Perhaps, if it is possible to "change" this function using a module, we could get a function always telling the kernel is valid and have kexec working on Milestone. Again, I'm not a kernel hacker, but that is my guess.

Hi, I'm sorry that I wont be much help but these guys might;
https://www.droid-developers.org/
irc://irc.freenode.net/#milestone-modding

Hi,
thanks for your comments so far.
To be more precisely i think this kernel driver is calling the secure monitor in some way. See here:
https://www.droid-developers.org/wiki/Secure_Monitor
There's also a structure defined in that driver. I think i'll have to compare some of the ioctl entries.
https://www.droid-developers.org/wiki/Secure_Services
I'll do some investigation on this issue and search the web for some userland source code using this driver.
Again, if someone knows more about it, your welcome
Cheers,
scholbert

scholbert said:
Hi,
thanks for your comments so far.
To be more precisely i think this kernel driver is calling the secure monitor in some way. See here:
https://www.droid-developers.org/wiki/Secure_Monitor
There's also a structure defined in that driver. I think i'll have to compare some of the ioctl entries.
https://www.droid-developers.org/wiki/Secure_Services
I'll do some investigation on this issue and search the web for some userland source code using this driver.
Again, if someone knows more about it, your welcome
Cheers,
scholbert
Click to expand...
Click to collapse
you don't have to search for the source, it's on SourceForge:
http://sourceforge.net/projects/milestone.motorola/files/

SophT said:
you don't have to search for the source, it's on SourceForge:
http://sourceforge.net/projects/milestone.motorola/files/
Click to expand...
Click to collapse
Yeah sure, i knew this
Anyway, thanks for the hyperlink!
In the meantime i grepped all binaries from the latest distribution.
I found out, that two applications are using /dev/sec.
1. dbvc_atvc_property_set
2. tcmd
If someone knows which package of source code they belong to... would save some time searching.
EDIT:
O.K. Google did it for me...
Seems that both binaries are proprietary code. Some early conclusions:
1. dbvc_atvc_property_set
This one is started as a service in init.mapphone_umts.rc and seems to use /dev/sec for granting rights to access OMAP secure world (e.g. read eFuse values for unique device id, IMEI etc.).
This binary contains a certificate which is not Milestone specific (XT720 uses the same).
So right now i don't know, if this certificate is needed to access /dev/sec or the application itself identifies itself as trusted application (signed app).
Would make sense, if the BP uses signed applications to access certain low level functions, e.g. read/write the eFuse bank.
2. tcmd
This one is also started as a service in init.mapphone_umts.rc to access a variety of devices. Seems to be related to data streaming or stuff.
As stated it has an entry for /dev/sec and it got no certifcate.
Would be interesting to get some more info about that.
Further comments....
P.S.: This bloody security stuff is making me sick
Regards,
scholbert

Hi again,
i just compared some of the defines in the kernel driver headers (/drivers/misc/sec/sec_core.h) with the ones xvilka reversed inside mbmloader.
Code:
...
#define API_HAL_KM_SOFTWAREREVISION_READ 33 // 0x21
...
#define API_HAL_NB_MAX_SVC 39 // 0x27
#define API_HAL_MOT_EFUSE (API_HAL_NB_MAX_SVC + 10) // 0x31
#define API_HAL_MOT_EFUSE_READ (API_HAL_NB_MAX_SVC + 15) // 0x36
...
For comparison see the table here:
https://www.droid-developers.org/wiki/Secure_Services
It is obvious that /dev/sec allows to access OMAP secure world and uses the above mentioned API calls to push information to userspace apps.
The question would be, if ioctl must be certified through the API using some key ...
O.K. i see this is deep down code creeping, but maybe someone understands what i try to work out
See ya,
scholbert

scholbert said:
O.K. i see this is deep down code creeping, but maybe someone understands what i try to work out
Click to expand...
Click to collapse
I think I know what you are trying to work out, but I can't think of any way to help
You're pretty much comparing the results of your findings with that of the mbmloader dump right?

I would like so much to fully understand what you are doing, but I can understand just a little..
btw I hope that you'll be glad to know that you have all my psychological support!

mystichobo said:
I think I know what you are trying to work out, but I can't think of any way to help
You're pretty much comparing the results of your findings with that of the mbmloader dump right?
Click to expand...
Click to collapse
Yeah, kind of... we know for sure there's an API to access security functions on OMAP. I just digged out some parallels in kernel code and mbmloader.
If we could make use of security functions from within kernel space (by using a tweaked module) this would be a nice playground.
Perhaps, there's any bug or backdoor we could shamelessly exploit to:
a. boot custom kernel with second boot
b. tweak the security system and enable some hidden functions inside OMAP
puffo81 said:
I would like so much to fully understand what you are doing, but I can understand just a little..
btw I hope that you'll be glad to know that you have all my psychological support!
Click to expand...
Click to collapse
Thanks a lot for pointing out
Best regards,
scholbert

scholbert said:
Yeah, kind of... we know for sure there's an API to access security functions on OMAP. I just digged out some parallels in kernel code and mbmloader.
If we could make use of security functions from within kernel space (by using a tweaked module) this would be a nice playground.
Perhaps, there's any bug or backdoor we could shamelessly exploit to:
a. boot custom kernel with second boot
b. tweak the security system and enable some hidden functions inside OMAP
Click to expand...
Click to collapse
That's what I thought
Surprised noone has looked into it earlier really
Anyway good luck with it, adding my moral support too.
Cheers,
hobo

mystichobo said:
Surprised noone has looked into it earlier really
Anyway good luck with it, adding my moral support too.
Click to expand...
Click to collapse
I got into contact with xvilka.
Obviously there'd been some investigations concerning this issue.
To be honest, i don't know if it's worth to digg a little deeper or if it will ever led to something useful in the end. Could be fun though
Perhaps it would be nice idea to tweak the driver and put some debug message in the code.
Another interesting thing to do would be a logging function.
This way it would be possible to get some insights of the API to secure monitor.
Anyway, i think it's never useless to discuss about some hacking here. At least were at xda-developers
If you like to tweak some kernel code, join in!!!
Have fun!
scholbert

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!"

Database Info

welcome