Related
10/19/11 Update: Added patches for the recently released GB sources to keyboard_patches-GB.tar.gz.
7/9/11 Update: New patch to export the "column-switch delay", which allows for much decreased CPU utilization/much better efficiency. See below for details.
3/23/11 Update: Add alternate "timer delay" patch to enable runtime configuration of keypad_timer delay. See below for details.
Attached is a kernel source patch that fixes the EB13 hardware keyboard dropped/skipped key press problem, at least for twice-pressed keys. It restores DI18-level responsiveness for the hardware keyboard.
I know dropped keypresses on the hardware keyboard has been a problem for a long time, even with DI18. There are likely multiple factors at play here, and this patch only corrects one of them. However, DK28/EB13 are particularly bad at dropping twice-pressed keys, and hopefully this patch alleviates this issue for most folks who experience it.
Bug details:
Sesquipedalian points out in one of the General threads concerning the issue that EB13 often drops twice-pressed letters on the hardware keyboard. For example, if one types "hello", often "helo" is emitted.
Yesterday I performed some timing tests and discovered that the EB13 keyboard driver delays 1/10th of a second (100 ms) between reporting "key_press" & "key_release" events. Unfortunately this delay is on the order of human muscle response, and when folks press the same letter twice in that 100 ms, the kernel will only be able to acknowledge one of the presses.
Keyboard driver background:
The Epic's keyboard driver is located at drivers/input/keyboard/victory/s3c-keypad.c in the EB13 kernel sources.
On initialization, the driver establishes an interrupt handler (s3c_keypad_isr) for keyboard ("keypad") events, which is executed whenever the kernel is interrupted with a key press. During an interrupt, the handler starts a timer (keypad_timer) to expire after "3 * HZ/100" jiffies (27 ms), and clears the interrupt request. The driver actually figures out which key was pressed/released in a separate routine that executes after the timer expires. Also, the interrupt is not immediately reenabled, so if a second keyboard event (either a key press or release) comes in before the timer expires, nothing additional happens.
When keypad_timer expires, the keypad_timer_handler function is invoked. This routine scans through each of the six "columns" (which roughly corresponds to the rows) of the keyboard looking for key presses & releases. In doing so, the driver delays 0.3 ms to ensure each column switch is accepted by the hardware, so the enitre routine should take rougly 1.8 ms to execute. This is actually quite a long time (but not inappropriately so) relative to the clockspeed of the processor, which is partly why the scanning is done outside the keyboard interrupt where operations "that take a while" are discouraged. So this isn't a bad setup, even if it might appear a bit unusual at first.
The end of the scanning routine (keypad_timer_handler) checks to see if any keys are currently held down, and if so it restarts keypad_timer. It must do this, becuase if a key is pressed & released "quickly", before the timer actually expires, then a release interrupt would never be generated (even if the interrupt was immediately reenabled). Hence, if a key is pressed & released "quickly", it is detected by the scanning routine after the second timer expiration. It's likely that the keybord only generates an interrupt on key press, so the timer is necessary to detect key releases. While a key is held down, the scanning routine keeps resetting the timer. Once a key release is detected, the timer is deactivated and the interrupt reenabled.
The bug:
Now, the problem is that keypad_timer, when restarted by the scanning routine, is set to expire after "HZ/10" jiffies (98 ms). This is an unusually long waiting time--four times as long as the original timer. If the same key is pressed twice in this interval, the scanning routine will pick it up only as a single press/release pair. If multiple, different keys are pressed in this interval, I believe the scanning routine will pick all of them up, but not necessarilly in the right order.
So the fix is to change the keypad_timer's restart expiration time to something more reasonable, like the 27 ms used by the interrupt handler. This decreases the waiting time to one in which it's unlikely that someone will be able to press multiple, or repeatedly press a key. As it turns out, that's exactly what DI18 does, so we know it works. It's totally unclear why Samsung changed it.
Oh well.
Edit: Originally I thought keys were latched, so press events would be detected by the scanning routine even if the key is released before keypad_timer expires. They're most certainly not though, the scanning routine likely polls the instantenous key (up or down) state, so a key press must be held for at least 27 ms so that the scanning may complete after the interrupt is serviced. If a key is held shorter than this, it will not be detected.
3/23/11: Alternate "timer delay" patch:
Also attached is an alternate patch that supercedes the original. It allows for runtime configuration of the keypad_timer delay via a sysfs exported timer_delay variable.
The current delay may be read with:
Code:
cat /sys/devices/platform/s3c-keypad/timer_delay
and a new delay may be set with:
Code:
echo N > /sys/devices/platform/s3c-keypad/timer_delay
where N is the delay in jiffies.
A delay of "1" yields the shortest timer, and the most responsive keypad possible, whereas a delay of "256" (1 second) (in most kernels) is the longest allowed. At that point the keyboard is already useless since any keypress results in either repeated characters or the "alternate character popup".
In most kernels (where HZ=256), the default delay is "7" (27 ms), which is the same as the original patch and DI18. A delay of "16" (63 ms) approximates the behavior of stock EB13/EC05.
Basically, the delay is the minimum amount of time one must hold a key down for a keypress to register. It's also the maxmimum time the kernel believes a key is "held down" after it's let go. For example, with a delay of "7" one must hold a key down for 27 ms to register as pressed, and no-more-than 55 ms later does the key register as being released.
Or for a better example, with a delay of "128" one must hold a key down for half a second, and once registered, the key is "held down" for an additional half a second. Which almost guarantees an application-level repeated keypress or the alternate character popup.
Ideally one would start with a delay of "7" and reduce by one until the timer is fast enough for your typing rate that you no longer have dropped keypresses. Although many folks will find that a delay of "7" is fast enough for them.
7/9/11: New "column-switch delay" patch:
Attached are two (mutually exclusive) patches to export the "column-switch delay" (column_delay) in addition to the timer_delay variable. The first applies against stock EC05 and supercedes all previous patches. The second (alt patch) applies against stock EC05 with the previous timer_delay patch already applied and should be used for custom kernels already containing that patch.
The column-switch delay is the amount of time, in µs, that the driver delays while switching between the six keyboard "columns" (actually rows) in the keyboard scaning routine. A delay is necessary to ensure that the column switch has been performed by the hardware before scanning a new column, otherwise ghost keypresses result.
However, the 300 µs delay specified by Samsung is very inefficient, particularly for "reasonable" timer_delay values. With theimpaler747's suggested timer_delay of 5, the keyboard driver, while holding a key down, consumes 9.7% of CPU time (empirically tested), at any clock rate. This is quite-likely responsible for folks' previous complaints that use of the hardware keyboard causes audio skips, poor game performance, decreased battery life, etc.
This patch allows this (default) 300 µs delay value to be modified through a sysfs exported column_delay variable. Similar to the timer_delay, it may be read with:
Code:
cat /sys/devices/platform/s3c-keypad/column_delay
and a new delay may be set with:
Code:
echo N > /sys/devices/platform/s3c-keypad/column_delay
where N is the delay in µs.
A delay of "1" is the most efficient (only 0.02% CPU utilization) but results in ghost key presses. In testing, I've found ghosting to disappear at delays of "3" and above. To provide some buffer, I've been using (and recommend) a delay of "5" for both column_delay and timer_delay values for the past week, and I've not run into any issues.
At a delay of "5", the keyboard driver is far more efficient, consuming only 0.2% of CPU time while keys are held. This hopefully translates into less stuttering/performance problems and better battery life.
Testing on other devices is needed (and appreciated!) to find a reasonable delay where ghosting doesn't appear, assuming that "5" is too low on some devices. Even delays of "10" and "50" (comparable to other keyboard drivers) result in ~0.3% and 1.7% CPU utilization respectively, which is much better than the Samsung default.
Mirror links:
GB kernel patches: keyboard_patches-GB.tar.gz
Column-switch & timer delay patch: epic_keypad_delays-EC05.diff (for stock EC05)
Column-switch & timer delay patch: epic_keypad_delays_alt-EC05.diff (for kernels with timer delay patch already applied)
Historical links:
Timer delay patch: epic_keypad_timer_delay-EB13.diff
Original patch: epic_keypad_timer_fix-EB13.diff
Nice work!
Wow , nice work! I wish we had people as smart as you working @ Samsung or Sprint.
Sent from my SPH-D700 using XDA App
Nice WORK!!!
Since you have this fix, this will definetly improve it a little, now u just need to find a fix to fix all missed letters.
Great Job, cant wait for an updated kernal with this in it.
Our poor developers on here work so hard to clean up manufactures phones issues and bugs and do an amazing job. They should fire everyone at samsung and hire all the devlopers here. lol
great job! so i take it this is both not necessary and not even compatible with DI18?
Well... downloaded Genocides kernel, was able to compile it after getting the toolchain and everything. Worked great. Loaded it on my zip, flashed it..
Kernel doesn't boot and suddenly my SD card is unreadable.. LOL! Guess I'll leave it to the pro's as I try to recover some data off my SD card...
Tried Genocides kernel flash zip, still didn't work, dang.
Lol , sorry I dont know why that is funny to me. Hope you get it working!
Sent from my SPH-D700 using XDA App
This fix seems to be worse as the special key popup is even more noticeable than before. Perhaps a change in timing would be better. Maybe Samsung changed this in response to complaints of the popup coming up when unwanted.
Sent from Bonsai 6.0.3
TheDub said:
Nice work!
Building Genocide with this patch applied for all interested testers...
Rodderick will need to be the one to officially include it in HIS! Kernel but now we all have something we can test... will post link when it's done compiling.
Click to expand...
Click to collapse
Rodderik is already all over it broham. =]
TheDub said:
Well... downloaded Genocides kernel, was able to compile it after getting the toolchain and everything. Worked great. Loaded it on my zip, flashed it..
Kernel doesn't boot and suddenly my SD card is unreadable.. LOL! Guess I'll leave it to the pro's as I try to recover some data off my SD card...
Tried Genocides kernel flash zip, still didn't work, dang.
Click to expand...
Click to collapse
thats my bad your sdcard got nuked it has to do with the i9000 having and internal and external sdcard storage...for now use my modified initramfs and not the new ported one on my git (says not to use i9000 initramfs in README on github)
mkasick thx for the info and i will put it in the kernel immediately and test
Now fix the QAOL bug
Sent from my SPH-D700 using Tapatalk
Top Nurse said:
This fix seems to be worse as the special key popup is even more noticeable than before.
Click to expand...
Click to collapse
I've seen mention of this before, but I'm not particularly familiar with the issue.
When the does the special key popup happen (besides long-pressing a letter)? Can you give an example that would somewhat-reliably recreate the problem?
mkasick the patch works beautifully! one note you might want to mention is any kernel developers that attempt to change the Kconfig or CONFIG_HZ=256 (it is set to 256 here but the Kconfig sets it to 1000 anyway) then that will throw this timer off (patched or not)
i think samsung missed the CONFIG_HZ=256 being used in the Kconfig...if we used the config's value in original settings (256/10) then that would give us 25.6 where as your patch is giving us 30 (3*1000/100)...i may fix this later but using your diff patch for now...thanks again
mkasick said:
I've seen mention of this before, but I'm not particularly familiar with the issue.
When the does the special key popup happen (besides long-pressing a letter)? Can you give an example that would somewhat-reliably recreate the problem?
Click to expand...
Click to collapse
Typing two letters quickly brings up the popup. Also the arrow keys act somewhat funny.
Sent from Bonsai 6.0.3
I will install this as soon as there is a Kernel that has it.
Nice work!
I hate to be "THAT" guy but..
If you press and old A for about a second you get that popup everyone is referring to.
Now if we are decreasing that timer unintentionally with this patch it could produce it popping up all the dang time on accident.
It was a known issue in DI18 I believe, that it would come up to frequently, Samsung probably fixed it by increasing that timer..
On genocide .3a and my rom I can't produce the hello bug reliably, the missed keys seem completely random and happen very very rarely with Swype gone.
Just a thought.
Originally Posted by TheDub View Post
Nice work!
Building Genocide with this patch applied for all interested testers...
Rodderick will need to be the one to officially include it in HIS! Kernel but now we all have something we can test... will post link when it's done compiling.
Rodderik is already all over it broham. =]
Click to expand...
Click to collapse
Nice to see, mine was a horrible fail anyways lol! but hey I was bored and you can't hurt anything by trying
TheDub said:
I hate to be "THAT" guy but..
If you press and old A for about a second you get that popup everyone is referring to.
Now if we are decreasing that timer unintentionally with this patch it could produce it popping up all the dang time on accident.
It was a known issue in DI18 I believe, that it would come up to frequently, Samsung probably fixed it by increasing that timer..
On genocide .3a and my rom I can't produce the hello bug reliably, the missed keys seem completely random and happen very very rarely with Swype gone.
Just a thought.
Nice to see, mine was a horrible fail anyways lol! but hey I was bored and you can't hurt anything by trying
Click to expand...
Click to collapse
i never new that would pop up til u just told me, i guess i dont type multiple "A's" often..
Forcystos said:
Now fix the QAOL bug
Click to expand...
Click to collapse
I wasn't sure what this was. Then I saw this post which describes it. Amusing.
Sadly I don't think it's an easy fix. This bug is known as ghosting, and it's due to the way the keyboard matrix works. If you simultaneously press keys in two different rows ("columns" in driver-speak), e.g., Q & A, pressing L is ambiguous. The hardware, since it lacks diodes, can't differentiate between L & O. Basically, if multiple buttons are pressed simultaneously all bets are off.
If this was a serious issue, as in folks were seeing spurious keypresses when not intentionally trying to perturb the hardware, we could fix it by modifying the keyboard driver to just ignore all press events when multiple columns have non-zero key masks. Basically this would result in simultaneous key presses not registering, whether they're in conflict or not.
Rodderik said:
one note you might want to mention is any kernel developers that attempt to change the Kconfig or CONFIG_HZ=256 ... then that will throw this timer off (patched or not)
Click to expand...
Click to collapse
I don't think it should. Keep in mind that jiffies (the unit timers use) are defined in terms of CONFIG_HZ anyways. Specifically, HZ=CONFIG_HZ (in kernel space), and time_in_seconds = time_in_jiffies/HZ.
So a delay of (3*HZ/100) is nominally 30 ms regardless of HZ. It only deviates because it's integer division, so while (3*1000/100) = 30 ms, (3*256/100) is 23 27 ms (edit: foolish math! multiply before divide). For the most part, it shouldn't matter too much.
Rodderik said:
(it is set to 256 here but the Kconfig sets it to 1000 anyway) then that will throw this timer off (patched or not)
Click to expand...
Click to collapse
Wait what? CONFIG_HZ is 256 in both my .config and autoconf.h. Is there some bug I'm not aware of that resets it to 1000, or are you using 1000 in your config?
Rodderik said:
i think samsung missed the CONFIG_HZ=256 being used in the Kconfig...
Click to expand...
Click to collapse
I think they used CONFIG_HZ=200 in DI18, and it was changed to 256 for Froyo. The Linux default (on i386 anways) is 250 IIRC. I'm not sure why Samsung bothered to change it, maybe it's a upstream thing. But 200 vs 250 vs 256 is somewhat arbitrary anyways.
Top Nurse said:
Typing two letters quickly brings up the popup. Also the arrow keys act somewhat funny.
Click to expand...
Click to collapse
Hmm, I tried to induce both of these but I can't seem to. Any other thoughts on it?
davidrules7778 said:
i never new that would pop up til u just told me, i guess i dont type multiple "A's" often..
Click to expand...
Click to collapse
Please don't take my first comments as criticism of any kind! Just discussing the topic at hand
I don't type multiple A's either but when changing that timer to be much shorter does that make the time required to hold down A to produce that pop up shorter as well?
I saw a few people report that it makes it more noticeable (accidental pop ups).
TheDub said:
Now if we are decreasing that timer unintentionally with this patch it could produce it popping up all the dang time on accident.
Click to expand...
Click to collapse
Ah, no, different timer. Changing the duration of keypad_timer merely changes how often the kernel keyboard driver checks to see if a key has been released. But if you hold a key down for 5 seconds, the kernel won't report a key_release event until 5 seconds after the key_press event. In the interim, other stuff might be happening like the "special character popup", or a key-repeat timer--but those are IME/app level and not controlled by the kernel.
If anything, this patch should strictly help. Say the "special character popup" happens after holding down a key for 0.5 seconds (it's about this). Previously, if you held a key down for 0.43 s, the release might not be detected until after 0.5 s and the popup would happen. Now, if you hold a key down for 0.43 s, the release would be detected no later than 0.46 s, and the popup won't show.
Think of it this way: a shorter keypad_timer results in more accurate key event timing, but (somewhat negligibly) increases CPU load due to having to run the scan routine more often.
Unfortunately I was one of the many people who have received a TF where the right speaker was significantly louder than the left. The reason for this is unknown by me as I've not disassembled my TF, and there are conflicting answers as to whether or not it is a software or hardware issue. However, with the help of fellow XDA member verkion for the initial fix and pointing me in the right direction, I've tinkered around enough that I feel comfortable sharing with the rest of the community. Let's get started.
Requirements:
-Root
-Left speaker actually working
-Root Explorer or similar file manager (recommended method)
--ADB if you don't use Root Explorer
--Text editing program (Notepad++ is recommended and free) if you decide to use ADB
Let's start with the recommended method, Root Explorer.
Step 1: Open Root Explorer and navigate to /system/data.
Step 2: Tap on the "Mount R/W" button.
Step 3: Tap and hold on the file "srs_processing.cfg" and once the menu comes up, select the "Open in Text Editor" option.
Step 4: Scroll down to:
//BLOCK: ( srs_spk_int : ) TruEQ - Internal Speaker Tuning
Here's where things can get kind of annoying, because you will have to change values, save & exit, then reboot and test your results. Anyway, there are 4 values you will want to focus on, and those are:
srs_spk_int:trueq_lband0 = 900.000000,-9.000000,0.700000 // TruEQ Left Band 0 Tuning (CF Gain Q) -
srs_spk_int:trueq_lband1 = 11000.000000,6.000000,0.500000 // TruEQ Left Band 1 Tuning -
srs_spk_int:trueq_lband2 = 400.000000,3.000000,0.7000000 // TruEQ Left Band 2 Tuning -
srs_spk_int:trueq_lband3 = 2500.000000,-9.000000,0.700000 // TruEQ Left Band 3 Tuning -
The values in bold are the only ones I've messed with so far with very good results. The beginning values have a maximum of around 16000, and 17000 results in your left speaker not working, something above 16000 but below 17000 may work but I haven't tried it. The two middle ones, I don't know the maximum because It wasn't necessary to up them that much. For example, mine look like this:
srs_spk_int:trueq_lband0 = 1400.000000,-9.000000,0.700000 // TruEQ Left Band 0 Tuning (CF Gain Q) -
srs_spk_int:trueq_lband1 = 16000.000000,10.000000,0.500000 // TruEQ Left Band 1 Tuning -
srs_spk_int:trueq_lband2 = 900.000000,7.000000,0.7000000 // TruEQ Left Band 2 Tuning -
srs_spk_int:trueq_lband3 = 7500.000000,-9.000000,0.700000 // TruEQ Left Band 3 Tuning -
For me, this works out wonderfully! However, results may vary.
Step 5:
Once you've changed those values, save & exit, then restart your TF and examine results. Repeat steps if necessary.
Method 2: ADB. NOTE: Make sure USB debugging is enabled.
Step 1: Connect TF to computer.
Step 2: In a command prompt/terminal navigate to where your Android SDK is and type adb devices to make sure your TF is recognized, if so, type adb remount. If it succeeds, proceed to step 3, otherwise you may need to either enable USB debugging, or install drivers.
Step 3: Type "adb pull /system/data/srs_processing.cfg" It will save the file in the same directory as adb.
NOTE: Do not close command prompt/terminal.
Step 4: Open "srs_processing.cfg" in Notepad++ or whatever qualified text editor you use. NOTE: Due to the nature of how Windows reads files, Notepad might not save the file correctly and definitely will not open it looking pretty. Wordpad might be the same. Basically, the file needs to be saved in UNIX format.
Step 5: Scroll up to Step 4 of the Root Explorer method and proceed.
Step 6: Save the file with Notepad++ or whatever qualified text editor you use.
Step 7: Back in command prompt/terminal, with the file saved over the original type "adb push srs_processing.cfg /system/data/"
Step 8: Reboot your TF as you normally would, or with adb method "adb reboot"
Examine results and repeat steps if necessary.
Attached below are the default srs_processing.cfg and my edited one.
Feel free to post back your own values, because they may be more refined than mine or may work for someone else better as well. ENJOY!
Update: Thanks to seshmaru, a typo was discovered. ASUS added an extra zero to the bold part in line: srs_spk_int:trueq_lband2 = 400.000000,3.000000,0.7000000 // TruEQ Left Band 2 Tuning - I've updated the default file as well as my edited one to remove this extra 0. While this did boost volume in the left speaker for me, it still was not on par with the right one.
Update 2: verkion suggests "turn off the Hard Limiting in the Internal Speaker Boosted section by setting:
hlimit_skip to 0 instead of 1. This gave me a little more "headroom" before distortion became unbearable. A hard limiter is a CLIPPING filter...it just "snips the sound" when it goes over a preset value instead of trying to "scale down the volume.""
NOTE: If your right speaker is more quiet of course look for the srs_spk_int:trueq_rband lines instead.
EDIT:
While looking at your fix I noticed something, this is what I pulled from my config:
Code:
srs_spk_int:trueq_lband0 = 900.000000,-9.000000,0.700000 // TruEQ Left Band 0 Tuning (CF Gain Q) -
srs_spk_int:trueq_lband1 = 11000.000000,6.000000,0.500000 // TruEQ Left Band 1 Tuning -
[B]srs_spk_int:trueq_lband2 = 400.000000,3.000000,0.7000000 // TruEQ Left Band 2 Tuning -[/B]
srs_spk_int:trueq_lband3 = 2500.000000,-9.000000,0.700000 // TruEQ Left Band 3 Tuning -
srs_spk_int:trueq_rband0 = 900.000000,-9.000000,0.700000 // TruEQ Right Band 0 Tuning (CF Gain Q) -
srs_spk_int:trueq_rband1 = 11000.000000,6.000000,0.500000 // TruEQ Right Band 1 Tuning -
[B]srs_spk_int:trueq_rband2 = 400.000000,3.000000,0.700000 // TruEQ Right Band 2 Tuning -[/B]
srs_spk_int:trueq_rband3 = 2500.000000,-9.000000,0.700000 // TruEQ Right Band 3 Tuning -
if you pay attention you will find that the 2 highlighted lines are a different length, even though they should be equal, woops Asus?
I modified this line
srs_spk_int:trueq_lband2 = 400.000000,3.000000,0.7000000 // TruEQ Left Band 2 Tuning -
to read
srs_spk_int:trueq_lband2 = 400.000000,3.000000,0.700000 // TruEQ Left Band 2 Tuning -
This fixed my unbalance problem.
Thanks - this was driving me nuts.....
looks like Asus left out a 0, did you try adding one?
No I removed a 0 based on the fact that all others have five 0's or there are a total of six digits
Sent from my Transformer TF101 using Tapatalk
Ah, yes that makes sense, it balanced your speakers correctly?
Thanks for posting this up Freeza. Honestly, I was too lazy to do this before. Did you notice the Left Speaker tends to distort far "earlier" (lower volume threshold) than the right one?
danielsjam...are you sure changing/removing a zero fixed or changed the balance? It shouldn't make any difference considering its a trailing zero. I'll test this in a few just to be certain.
Thanks!
verkion
seshmaru said:
NOTE: If your right speaker is more quiet of course look for the srs_spk_int:trueq_rband lines instead.
EDIT:
While looking at your fix I noticed something, this is what I pulled from my config:
Code:
srs_spk_int:trueq_lband0 = 900.000000,-9.000000,0.700000 // TruEQ Left Band 0 Tuning (CF Gain Q) -
srs_spk_int:trueq_lband1 = 11000.000000,6.000000,0.500000 // TruEQ Left Band 1 Tuning -
[B]srs_spk_int:trueq_lband2 = 400.000000,3.000000,0.7000000 // TruEQ Left Band 2 Tuning -[/B]
srs_spk_int:trueq_lband3 = 2500.000000,-9.000000,0.700000 // TruEQ Left Band 3 Tuning -
srs_spk_int:trueq_rband0 = 900.000000,-9.000000,0.700000 // TruEQ Right Band 0 Tuning (CF Gain Q) -
srs_spk_int:trueq_rband1 = 11000.000000,6.000000,0.500000 // TruEQ Right Band 1 Tuning -
[B]srs_spk_int:trueq_rband2 = 400.000000,3.000000,0.700000 // TruEQ Right Band 2 Tuning -[/B]
srs_spk_int:trueq_rband3 = 2500.000000,-9.000000,0.700000 // TruEQ Right Band 3 Tuning -
if you pay attention you will find that the 2 highlighted lines are a different length, even though they should be equal, woops Asus?
Click to expand...
Click to collapse
oh wow. I hadn't noticed. GREAT find.
verkion said:
Thanks for posting this up Freeza. Honestly, I was too lazy to do this before. Did you notice the Left Speaker tends to distort far "earlier" (lower volume threshold) than the right one?
danielsjam...are you sure changing/removing a zero fixed or changed the balance? It shouldn't make any difference considering its a trailing zero. I'll test this in a few just to be certain.
Thanks!
verkion
Click to expand...
Click to collapse
Yeah, I do notice it a tad, but I can definitely live with it! I was hoping you wouldn't mind.
Yes fixed my left speaker. Before this I could barely hear my left. If not wrong they are using ALSA sound drivers. You may find more info at the ALSA web site.
Sent from my Transformer TF101 using Tapatalk
I pushed the OP's attached file (srs_processingDEFAULT.zip) then my left speaker became more louder. I pushed back my pulled stock original file from my TF but then my right speaker is now louder.
Stock pulled file attached.
Updated the OP to reflect seshmaru's findings.
BTW, anyone know what srs_processing_JN101.cfg is for? It's almost identical to the original cfg and it showed up for 3.1. if you change stuff in there, sound seems to be unaffected?
Thanks!
verkion
Since sharing is caring, here's my srs_processing.cfg
You'll notice in the TrueEQ settings, my center frequencies are completely different (or quite different at any rate), because I was trying to get a nice flat response. It's better but not very good b/c the speakers suck at the end of the day.
I ALSO turned down the gain in the following section:
Code:
HLimit - Internal Speaker Boosted
hlimit_boost = 2.000
This it to prevent the distortion in the left speaker but has the negative effect of making everything quieter.
Incidentally, the reason why I am trying to get a flat response is because you'll notice that there are 10 GEQ settings for "Internal" and 10 GEQ settings for "External". They are all set to 0 at the moment but you COULD tweak them to your liking. Each of the presets appears to be a 10-band equalizer, probably fairly standard frequency spacing, controlled in dB gains. i.e. you actually have a built in Equalizer that isn't really being utilized properly.
You can have a bunch of different profiles and then switch between them by specifying which preset you want to use:
Code:
geq_int_preset = 0 where 0 is the preset number
This line is found at the top of the srs_processing.cfg file.
Lots more to play with in that config file. I wish there was some way to "reinitialize" the sound engine without having to reboot. Then, a program w/a gui could be written that allows this stuff to be adjusted by the user as long as they had root access.
Thanks!
verkion
verkion said:
BTW, anyone know what srs_processing_JN101.cfg is for? It's almost identical to the original cfg and it showed up for 3.1. if you change stuff in there, sound seems to be unaffected?
Thanks!
verkion
Click to expand...
Click to collapse
It's probably for the Eee Pad Slider.
i tryed your fix and it works really nice! but i'm "scared" about the stress that the left speaker have to sustain. i notice that there is a very strong vibration of the left side of the back cover so i think that the left speaker isn't equal to the right but it's smaller.
i don't want a damaged left speaker so i renounce to the balancing
I think the problem with speaker balance is due to the fact that the right side as more opening (microsd, hdmi) for the sound waves to get to our ears...if you look at the left side those tiny holes on a metal casing don't let enough sound waves thought that's why when you listen to some music at a higher level you feel the back plastic casing vibrating... Like a subwoofer made of plastic
Sent from my Desire HD using XDA Premium App
andrew2511 said:
i tryed your fix and it works really nice! but i'm "scared" about the stress that the left speaker have to sustain. i notice that there is a very strong vibration of the left side of the back cover so i think that the left speaker isn't equal to the right but it's smaller.
i don't want a damaged left speaker so i renounce to the balancing
Click to expand...
Click to collapse
Interesting. I haven't applied this fix yet and noticed my right speaker (the louder one) is already having the vibrating effect.
So wouldn't it be normal that the left speaker, the quieter one, would also make the case vibrate around it if you turn up the volume to balance with the other speaker?
hi all
after trying this my speakers is now balanced
its works!!!
ASUS is using a 'static' version of that processing system - it only reloads at boot. Sorry guys. There's an interactive version with various UI and import/export features too - but generally it's only active during development/QA - at retail it is often locked-out.
Nice find on that typo - now I have to go debugging
Shawn_230 said:
Interesting. I haven't applied this fix yet and noticed my right speaker (the louder one) is already having the vibrating effect.
So wouldn't it be normal that the left speaker, the quieter one, would also make the case vibrate around it if you turn up the volume to balance with the other speaker?
Click to expand...
Click to collapse
the right vibrates too but applying the fix the left back cover will vibrate more and more than the right one. so balancing the speakers, the left having the same volume of right seems to be stressed much more
tested on iron maiden
UPDATE [11th September 2011]
Modified the SetCPU profiles:
Removed AC-charging Overclock (subject to temperature warnings mentioned in replies)Reduced some MAX values (has added 5 hours of real-world battery use and makes no noticable difference in performance)Added an optional < 101% profile to default the maximum clock speed to 729MHz (does not reduce performance, adds 2 hours effective runtime)Specified the Priority values (which I had forgotten to mention originally)
Introduction - The Desire S Battery Problem
As a fellow Desire S owner, you no doubt agree that it is a lovely phone: sleek, thin, relatively light, feature-filled... almost everything anyone could ever want from a phone!
However...
As a fellow Desire S owner, you no doubt agree that the battery life (on the Stock Sense ROM, regardless of how strict your PWM settings) is rather pathetic.
I have two HTC Desire S phones (one for myself, one for my wife), and both of them have almost exactly the same runtime (give or take a few minutes) when run in identical test conditions... no more than 18 hours (almost all of which with the display turned off) between charges, and less than 8 hours average with light-to-moderate screen-time when in use.
Bottom line: it's rather pathetic, and unacceptable.
Thankfully, we have options now... and this guide provides you with the option I have chosen for my Desire S phones.
Introduction - The Sacrifice
HTC Sense is (to many) considered a very "pretty" GUI, with nice animated transitions, a rounded feel etc, however it comes at a price: it's a battery hog!
I have played with many Sense 2 and Sense 3 ROMs on the Desire S, all of which share the common result of dimished battery runtime...
Bottom line: The simplest way to get more battery life is to sacrifice Sense entirely!
Just to point out: HTC Sense is the only sacrifice this guide makes in the persuit of optimal battery life! Unlike other guides, this one doesn't compromise any other features, or ANY performance (in fact, I've found performance with the setup described here to be even better than the stock ROM... noticably so!)
DISCLAIMER
I cannot (and will not) be held responsible for any losses or damages resulting from your use of this guide or the materials it contains. If you brick your phone, you've done something wrong and the fault is your own.
You should follow this guide with a fully charged battery, and if possible perform all steps involving a PC from a Laptop, with your phone connected via USB to minimize the risks associated with sudden power loss on your mains supply.
Stage 1: S-OFF
Aside from a lucky few whose Desire S came with S-OFF as a factory default, most of us have S-ON handsets.
With S-ON, you cannot flash a custom ROM onto your Desire S... but fear not, as there is now a FREE (and insanely simple) way to unlock our handsets, giving us the precious S-OFF we require.
You will require the Android SDK to be installed on your system, as well as the USB drivers for the HTC Desire S (these are installed as part of HTC Sync, though you should close HTC Sync from the system tray before proceeding as the S-OFF process will refuse to run with HTC Sync running at the same time)
Head on over to http://revolutionary.io/ to download their tool. This guide presumes you are using Windows, though it should be easy enough - if you're a Linux user - to adapt this information for your Linux platform.
Once you press the link to download Revolutionary, you will notice that a form appears asking for certain information. You'll see a screenshot of this below, but before we get to that there's something you must do...
Open a Command Prompt window from the Platform-Tools directory of the Android SDK.
From that Command Prompt window, type adb devices. Presuming you have the HTC Desire S drivers installed correctly, and your handset connected to your PC via USB, you should something like this:
{
"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"
}
LEAVE THIS COMMAND PROMPT WINDOW OPEN, WE'LL NEED IT AGAIN SHORTLY
The third line of text begins with your handset's serial number.... you will need to enter this into the form on the Revolutionary website in order to generate your Beta key:
Once the Revolutionary zip file has downloaded, extract its contents into a folder on your PC (doesn't matter where, so long as you have access to that location).
Run revolutionary.exe following the instructions provided (it's a very quick and simple process... the automated portion of which shouldn't take more than 2 or 3 minutes to complete)
When it prompts you to install the Recovery mod, do it! You will need it for the next stage of this guide!
Your HTC Desire S now has S-OFF, is equipped with a version of ClockWork Recovery, and is ready to recieve the custom ROM! (All is good with the world).
Stage 2: The Custom ROM
IMPORTANT - THIS WILL FACTORY RESET YOUR PHONE (UNAVOIDABLE) SO DON'T FORGET TO BACK UP WHATEVER YOU NEED BEFORE YOU PROCEED WITH THIS GUIDE! YOU HAVE BEEN WARNED!
NOTE You will either need a spare MicroSD card, or to back up your existing MicroSD card and make it accessible to have files written to it from your PC (I use a card reader, but you can always use the USB Mass Storage feature of the phone itself to access the SD card in your phone from your PC)
The custom ROM of choice is NeoLojik's CyanogenMod 7, lovingly and paintakingly prepared especially for our HTC Desire S handsets, with quite probably the most prompt and spectactular support from NeoLojik himself.
I have chosen NeoLojik's CM7 ROM because it has proven (after exhastively testing other ROMs for the Desire S) to provide me with the very best battery performance, as well as all of the settings you will tweak as part of this guide.
Download (from the ROM's thread linked above):
The latest version of his ROM
The recommended Tiamat Kernel
The recommended version of the Google Apps package
To save time later, download The Android Market 3.1.3 APK
(You can download the APK from your phone directly after you've completed this portion of the guide, if you prefer)
Place the three ZIP files, as well as the Android Market APK, on the root folder of your MicroSD card (by "root" I mean the initial path of the SD card, which is whatever drive letter it mounts as on your Windows PC - e.g. "H:\")
Now, with your phone still connected to your PC via USB (and the SD card put back into your phone, if required), return to the Command Prompt window we used earlier and type adb reboot recovery
Now direct your attention to your phone
Once the Recovery Menu has loaded (should take about 30 seconds) we will follow some simple instructions below... but first, a few points on how to use Recovery:
Use the Volume Up and Down buttons on your handset to highlight one of the displayed options
Use the Power button to trigger the highlighted option.
wipe data/factory reset
wipe cache partition
apply update from sdcard
choose zip from sdcard
update-cm7.1.0-RC1-DesireS-Nexx-signed.zip (or whatever the ROM's filename is at your time of downloading... it will change as the ROM evolves)
apply update from sdcard
choose zip from sdcard
Tiamat_Saga-v1.1.2.zip (or whatever the filename is for the recommended Tiamat kernel at your time of downloading)
apply update from sdcard
choose zip from sdcard
gapps-gb-20110613.zip (again, filename might be slightly different for you)
Remembering with each selection to navigate to the "YES" option in the confirmation menu (this exists to prevent you from accidentally flashing the wrong file onto your phone)
Now, from your PC (or from the Recovery menu... doesn't matter which), you want to reboot your phone! To do this from the PC, you will just type adb reboot into the Command Line window we used previously.
Your phone will now boot with the new ROM (CyanogenMod), and has been factory reset (so you'll have to run through the first-run configuration wizard).
NOTE: Don't be scared if (after the boot animation disappears) the screen remains black for a minute or so! The first boot of the new ROM (especially with the Tiamat Kernel) does take a bit longer than every subsequent boot there-after. Just give the phone a few minutes, and press the Power button. You SHOULD see the Lock screen once the device is ready!
Run through the first-run wizard following instructions provided (fairly strait forward), though keep in mind that (at the time of writing) the wizard does not prompt for a WiFi connection until AFTER it attempts to log in to your Google account! Fear not, though, as when it fails to connect to your Google account (presuming you don't have Mobile Data available to you), it'll then prompt for a WiFi network and repeat the Google account login afterwards.
Once you have completed the first run config, open the "File Manager" app included as part of the ROM.
Navigate to /sdcard and run the com.android.vending-3.1.3.apk file. You'll be prompted to allow unknown sources, you want to tick that box and click on the APK again.
Once you've installed this, you will be running the latest (and greatest) version of Android Market, which (amongst other things) enables you to use a different Google account for your Apps (very useful if you want to install your paid applications on your wife's phone, as I have)
Welcome to CyanogenMod!....
Stage 3: Battery-saving Mega Settings [Menu-by-Menu]
The Settings I'm providing you here are the results of countless hours of experimentation (as well as logic and common sense). They have proven to provide the best degree of battery runtime with absolutely no performance or feature sacrifice!
If a menu or entry within a menu isn't mentioned, it's because it has no bearing on power saving!
Wireless & networks
Wi-Fi settings
Network notification = OFF
Press the Menu button, then Advanced
Wi-Fi sleep policy = NEVER
Call settings
Vibrate on answer = OFF
Vibrate every 45 seconds = OFF
Vibrate on hangup = OFF (NOTE: I leave this ON as my one concession as it's the only way you will know if a call drops out on you unexpectedly!)
Vibrate call waiting = OFF
Always use proximity = OFF
Enable sensor rotation = OFF
Voicemail notifications = ON (it doesn't save power, but seriously... you want it on!)
CyanogenMod settings
Display
Automatic backlight
Light sensor filter > Enabled = OFF (If enabled, unnecessarily drains more battery life! The feature itself is pointless as there is no difference to the UX with it Enabled or Disabled!)Light levels
Use custom = ON
Screen dim level = 14
Allow light decrease = ON
Edit other levels...
This is what I consider to be the most optimal set of levels:
Lower | Screen | Buttons
0 | 21 | 2
160 | 31 | 2
255 | 35 | 2
320 | 40 | 0
640 | 50 | 0
1280 | 75 | 0
2600 | 90 | 0
5800 | 130 | 0
8000 | 200 | 0
10000 | 255 | 0
Press Save & apply (scroll to the top to find the button)
NOTE: You may want to play around with some of the values in this table, as screen brightness is not a "one size fits all" affair, and what I can see clearly might not be so clear for you (or vice-versa). Basically, use those levels as a starting point, and tweak them from there until you find the best settings for you in various lighting conditions.
I will say this, you don't want to set the Buttons value above 0 if you can see the buttons even faintly at a given light level. The backlighting for the buttons is a surprising battery drain (it's calculated as part of the Screen's power consumption in the Battery Usage menu). Bottom line: if you don't need any lighting on the hardware buttons in order to use them even in pitch blackness, then set the value of Buttons for each set in the table to 0 and squeeze more life out of your battery!
Performance (press OK when the warning is displayed)
CPU settings
Available governors = SMARTASS ("SMARTASS" has been designed specifically [and brilliantly] to scale the CPU frequency with such a perfect balance of performance-on-demand versus power saving... it's the perfect choice!)
Min CPU frequency = 192
Max CPU frequency = 1036 (We'll be using SetCPU [full version, bought from the Market] to set up some magical CPU profiles later in this guide, saving us LOTS more battery life!)
Set on boot = ON
Sound
Haptic feedback = OFF (Remember: The phone's vibrator consumes more power than playing a beep or other short tone through the speaker at even the highest volume!)
Accounts and sync
Auto-sync = OFF (Auto-sync being disabled saves both battery power, as well as bandwidth on your Mobile Data tarif [2G and/or 3G dependant on carrier]. Really, you should just "sync on demand" as and when you want/need to!)
This concludes the Settings portion of the guide!
Stage 4: SetCPU (for ROOT users) configuration
SetCPU for ROOT Users is available for on the Android Market for just £1.25 (or $1.99 USD). Not only does this program enable you to overclock/underclock your phone's CPU, but more importantly it enables you to provide Profiles, to scale the CPU based on the operational status of your phone.
This is well worth the infintismal pricetag, as the potential power savings (at no performance cost) is more than significant!
Open SetCPU, go to the Profiles tab:
Enable = ON
Notifications = ON (Really this is up to you! I like to have notifications for when the profile is changing to ensure that the CPU is scaling properly, and to ensure that my profiles are the best they can be for performance/battery balance)
Add Profile
Profile = Charging AC
Max = 1036800 (Potentially, you could set it up to 2GHz, but I have stability (and heat) concerns, and I can't possibly see any circumstance where 2GHz would be remotely useful! If you do elect to overclock (particularly whilst charging), you will need to add a profile (with 100% priority) to drop the Max value if the temperature exceeds 45 C)
Min = 192000
Scaling = smartass
Press Save
Add Profile
Profile = Charging USB
Max = 1036800 (Basically 1GHz [original] CPU clock. We don't want to bleed into the minimal input of power provided by USB, so this is the best setting to use)
Min = 192000
Scaling = smartass
Press Save
Add Profile
Profile = Battery <
Battery < = 75%
Max = 652800
Min = 192000
Scaling = smartass
Press Save
Add Profile
Profile = Battery <
Battery < = 50%
Max = 576000
Min = 192000
Scaling = smartass
Press Save
B]Add Profile[/B]
Profile = Battery <
Battery < = 30%
Max = 422400
Min = 192000
Scaling = smartass
Priority = 80
Press Save
Add Profile
Profile = Screen Off
Max = 345600
Min = 192000
Scaling = smartass
Priority = 60
Press Save
Add Profile
Profile = Time
Time = 01:00 - 08:00 (NOTE: Substitute the given range with whatever your daily sleeping hours are!)
Max = 345600
Min = 192000
Scaling = smartass
Priority = 70
Press Save
The following profile is optional... and (if used) would specify your default clock speed
Add Profile
Profile = Battery <
Battery < = 101%
Max = 729600
Min = 192000
Scaling = smartass
Press Save
Feel free to experiment with other profiles as well! Perhaps you may want to procedurally reduce your CPU speed based on Battery % in a more gentle way... this is certainly possible, and would squeeze even more life out of your battery.
You should also feel free to use lower MAX values for each setting (I would strongly advise against higher values) if you feel that the lower clock speed makes little-to-no noticable difference in performance as you use your phone.
Personally, I notice no difference between 729600 and 1038600!
Stage 4: Recalibrating your Battery
Install the Battery Calibration app (FREE on the Android Market).
If your phone isn't charged, charge it up so that it is showing 100% (with the Green LED lit).
Run Battery Calibration and press the Battery Calibration button. Immediately unplug the power/USB cable from your phone, and allow it to run (as normal) until fully discharged.
Once the phone has switched itself off, plug it into the AC cable (using the mains charger).... and LEAVE YOUR PHONE SWITCHED OFF until the LED indicator is lit green!
You may want to repeat the discharge/recharge cycle one or two more times (as many people claim that this provides a better calibration)... though really that just entails running your phone on the battery until it is fully discharged, then allowing it (whilst switched off) to fully recharge on the mains adapter (AC)... which is not what most people would normally do as a routine.
Potential Stage 5: Tasker
Tasker (£3.99 on the Android Market) enables you to create profiles which automatically change various settings based on one or more given criteria. This even includes the ability to switch on and off features of your phone such as WiFi, Bluetooth, GPS, GSM, Mobile Data and Airplane Mode.
By creating suitable Tasker profiles, you can squeeze even more battery life out of your phone!
If it's of benefit to people (let me know in the comments) I can expand this guide to include step-by-step instructions on creating the various profiles I would recommend in order to squeeze more battery runtime out of your phone without sacrifising features/functionality.
General Battery Storage/Maintenance Advice (Applies to all Lithium-Ion Batteries, including those used in Laptops)
To prolong the operational lifespan of your battery, you should not really allow your battery to run for very long below 50% charge, as "topping up" a half-charged battery generates less wear and tear on the battery, prolonging its overall lifespan.
NEVER leave your phone fully discharged for more than an hour, or the LiIon cells will begin to degrade, meaning your battery will never be able to physically hold as much charge. Indeed, the longer you leave a discharged battery, the less overall capacity your battery will retain.
NEVER store your battery (even if the phone is running at the time) in cold conditions! As a general rule of thumb, if it's "a little chilly" for you, it's unhealthy for the battery!
Both of the above tips form respectively the Number 1 and 2 causes of battery death! Don't let your battery become another statistic!
If - like me - you have one or more "spare batteries", you will likely be tempted to store them when they are fully charged (100%). This sounds like a good thing to do, but actually it can have (to a slightly lesser degree) the same damaging effect on the battery as leaving it fully discharged for any prolonged period of time!
The absolute best level of charge at which you should store a battery is at 50%, or as close there-to as possible!
Dependant on how often you find yourself recharging your battery, you should recalibrate it between every 3 to 6 months (the more often you discharge/recharge, the less often you should recalibrate).
Also, you should ALWAYS recalibrate after having flashed a new (or updated) ROM and/or Kernel!
My results using the exact configuration [excluding Tasker] detailed in this guide...
As I stated above, with the way I use my Desire S, I was lucky to get 8 hours of what I would call "light-to-moderate" use whilst running on the battery!
With the configuration detailed in this guide, I have now had a successful "100% to discharged" usage of 46 hours (under the exact same usage conditions as when I was using the stock ROM factory-installed on the phone (and updated OTA ~ a week ago).
This is a VERY significant improvement, though I must stress that results will vary heavily based on how much (or what) software you're running on the phone, how often you're interacting with it, how long you spend in calls etc.
Basically, every phone is different, and every operator (me, you, everyone) is different.
Please also keep in mind that your phone won't "settle in" to the new settings in terms of battery runtime until you've done 2 or 3 discharge/recharge cycles (as explained in the Battery Calibration portion of this guide)
Conclusion
There are plenty of third-party ROMs out there, and (obviously) I can't physically test them all! I have tested what I believe anyone would consider to be a perfectly suitable number (more than a dozen now), and have found the exact combination detailed in this guide to provide the very best battery runtime for me.
I understand that some of you will likely have your own ROM preference (for various reasons), but I hope that at least some sections of this guide will be useful to you.
If you just want to get the very best battery performance out of your Desire S, and either don't particularly care what ROM you use, or (like me) happen to love Cyanogen anyway... this guide will fit you like a glove!
Need any more advice?
No problem... post your comments and questions as a reply to this guide, and I'll answer anything I can, as promptly as possible (please consider that I have a company to run, and a life beyond the Internet... so replies might not always be "instant")
I hope you like this guide, and more importantly... I hope you enjoy your new-found battery runtime!
Unfortunately, I'm a Sense fan. ...so will take persuding to move away from the interface, as been using it for many years, but, I still appreciate a piece full of insight and advice written for the communities benefit. Well done and thanks for sharing.
I'll reference this in the development INDEX next to CM7 ROMS
ben_pyett said:
Unfortunately, I'm a Sense fan. ...so will take persuding to move away from the interface, as been using it for many years, but, I still appreciate a piece full of insight and advice written for the communities benefit. Well done and thanks for sharing.
I'll reference this in the development INDEX next to CM7 ROMS
Click to expand...
Click to collapse
Yeah, I can understand why so many people strictly adhere to Sense ROMs... for me the "slight prettiness" of Sense doesn't justify the hammering of the battery... especially as I actually preffer the L&F of Cyanogen anyway
If I have gotten 18 hours with almost always screen off I returned the phone. With nomal usage my phone last more than one day. Keeping the screen almost always off last almost 2 days with wifi and sync turned on (to be honest, never reached that again). ROM is whether LBC or rooted stock whith stock HTC kernel. So I can find any problem there. Nevertheless, this is a smartphone, and I always have a charger with me
I will try CM and what the battery life is like.
Profile = Charging AC
Max = 157440 (Potentially, you could set it up to 2GHz, but I have stability concerns, and I can't possibly see any circumstance where 2GHz would be remotely useful!)
Min = 192000
Scaling = smartass
Press Save
Fried CPU kgo. Overclock + Charging = Excessive heat being generated.
zeekiz said:
Profile = Charging AC
Max = 157440 (Potentially, you could set it up to 2GHz, but I have stability concerns, and I can't possibly see any circumstance where 2GHz would be remotely useful!)
Min = 192000
Scaling = smartass
Press Save
Fried CPU kgo. Overclock + Charging = Excessive heat being generated.
Click to expand...
Click to collapse
I have tested this setting with my own phone, and the heat increase was LESS than 1 Celcius (infintismal)... sure, if you wanted, you could use a lower value.
Its your call, your thread, I just feel that it isn't a good idea. At least even consider placing a warning adjacent to it.
LaKraven said:
I have tested this setting with my own phone, and the heat increase was LESS than 1 Celcius (infintismal)... sure, if you wanted, you could use a lower value.
Click to expand...
Click to collapse
You could add a setcpu profile for limitting the temperature. I dont overclock, but when im using my phone while charging, it gets hot, so I limit the temperature at 41.1 C , so 768mhz - 245mhz , on demand.
lbc ROM, stock kernel
zeekiz said:
Its your call, your thread, I just feel that it isn't a good idea. At least even consider placing a warning adjacent to it.
Click to expand...
Click to collapse
I've updated the guide (see the update notes at the very top of the post). The on-AC overclock setting has been removed, and I have placed a warning about overclocking next to it.
Updated the post to address a typo in one of the SetCPU profiles (I missed a 0 from the end of 345600).
I will have done this process by tomorrow, I'm sure - even bought Tasker. - Hoping I wont damage something in the process since I've never dealt with an HTC phone before. :/ Since my mom bought it to me as a present, she just peeks in from time to time to check wth am I doing with it - gotta keep a satisfied grin on my face all the time while I'm figuring how to fix this problem lolz
Really you just need to follow instructions (read everything through at least twice before you begin), be patient... and double-check everything you're abuot to do before you do it.
You can't do any more than that!
I've flashed both of these phones so many times now, and the only mistake I ever made was forgetting to clear the cache (Which results in an infinite boot loop or "soft brick", easily recovered by constantly typing "adb reboot recovery" in your Command Prompt, which will eventually make the phone re-enter recovery mode (exiting the infinite boot loop), at which point you can wipe, clear cache, reflash, and relax!
LaKraven said:
Really you just need to follow instructions (read everything through at least twice before you begin), be patient... and double-check everything you're abuot to do before you do it.
You can't do any more than that!
I've flashed both of these phones so many times now, and the only mistake I ever made was forgetting to clear the cache (Which results in an infinite boot loop or "soft brick", easily recovered by constantly typing "adb reboot recovery" in your Command Prompt, which will eventually make the phone re-enter recovery mode (exiting the infinite boot loop), at which point you can wipe, clear cache, reflash, and relax!
Click to expand...
Click to collapse
Funny, so true, in fact, did just that myself about two minutes ago while testing another ROM, meant trip to PC, plug in, power on, and then sorted adb reboot recovery
Swyped from HTC Desire S using XDA Premium
ben_pyett said:
Funny, so true, in fact, did just that myself about two minutes ago while testing another ROM, meant trip to PC, plug in, power on, and then sorted adb reboot recovery
Swyped from HTC Desire S using XDA Premium
Click to expand...
Click to collapse
Good to know I'm not the only one! It's such an easy step to overlock... just a good job it's also the least fatal mistake to make!
and then this
.. Ther is no Path in User, but there is in System...Geez, so tired..What do....:/ I'm all set to flash, just this thing I think...
You need to reinstall Java JDK.
This has happened to me before!
LaKraven said:
You need to reinstall Java JDK.
This has happened to me before!
Click to expand...
Click to collapse
Thx man I did that, I also don't have any command prompts in here :
C:\Program Files (x86)\Android\android-sdk\platform-tools
Bombastc said:
Thx man I did that, I also don't have any command prompts in here :
C:\Program Files (x86)\Android\android-sdk\platform-tools
Click to expand...
Click to collapse
Open Windows Explorer, navigate to C:\Program Files (x86)\Android\android-sdk\platform-tools
Hold down SHIFT and RIGHT-CLICK in on that folder
Click "Open command line window here"
You're then ready to start using ADB commands
LaKraven said:
UPDATE [11th September 2011]
Potential Stage 5: Tasker
By creating suitable Tasker profiles, you can squeeze even more battery life out of your phone!
If it's of benefit to people (let me know in the comments) I can expand this guide to include step-by-step instructions on creating the various profiles I would recommend in order to squeeze more battery runtime out of your phone without sacrifising features/functionality.
Click to expand...
Click to collapse
I would really like that. Yesterday followed your guide and learning new things as i went about the CyanogenMod. I'm curious now how far my battery will bring me :-D.
At the moment i'm using the trial version of phoneweaver and automateit, which are nice programs, but if tasker is more efficient although having a steeper learning curve, i will switch in an instant.
shizuku said:
I would really like that. Yesterday followed your guide and learning new things as i went about the CyanogenMod. I'm curious now how far my battery will bring me :-D.
At the moment i'm using the trial version of phoneweaver and automateit, which are nice programs, but if tasker is more efficient although having a steeper learning curve, i will switch in an instant.
Click to expand...
Click to collapse
As a tasker convert myself, I can also say that you'll read a great review of some of its functionality and a slightly biased review of the product by wnp_79 as part of his [GUIDE] Update 28/06/11: HTC Desire S Guide (V1.03) For Newcomers to Android which is in a sticky at the top of the forum.
Hi,
I was working on getting USB-OTG running on my phone and went to check the status using dmesg. I found that all key presses and finger movements appeared in the log. I come from a linux background and this seems...wrong. dmesg is not exactly a secure storage place for everything that happens on the system, including the entering of my password. I'm wondering if this is normal behavior, if I have some sort of debugging turned on, or what? Has anyone seen this before?
Here's what it looks like (I changed some numbers to prevent sharing personal information, but the key Pressed/Released have unique identifiers for each keyboard key):
<4>[30238.278458] [TSP] Flags Counted channels: t:0 a:0
<4>[30238.280631] [TSP] calibration was not decided yet
<4>[30239.492978] [TSP]### Finger[0] Down (1,100) - touch num is (1) status=0xc0, orient = 7
<4>[30239.529093] [TSP] Waiting for diagnostic data to update, try 1
<4>[30239.532518] [TSP] Flags Counted channels: t:9 a:0
//snip//
<4>[30239.728349] [TSP]### Finger[0] Up (2,200) - touch num is (0) status=0x20, orient = 7
<4>[30240.671821]
<4>[30240.671863] key Pressed : key 00 map 00
<4>[30240.861710]
<4>[30240.861721] key Released : 00 map 00
<4>[30241.147448]
<4>[30241.147490] key Pressed : key 7 map 16
<4>[30241.279697]
<4>[30241.279708] key Released : 7 map 16
This is a function of how Samsung built their addons to the Sidekick. The USB debugging gives you a warning that it can share sensitive information for a reason. This is normal for our phone, I can't speak for the rest of the samsung phones, but stock, that's what happens.
Thanks! So is there any way I can enable and disable this? I don't really need that much debugging information all the time. Otherwise, is there a way that I can set permissions to prevent applications from reading the output?
There's no way to disable that, short of rebuilding the entirety of the system from scratch and disabling debugging (not really feasible). As far as I've seen and as far as I know, there's no need for any apps to monitor logs, so none should need permissions to them. System apps should not have permissions to the logs, but it's possible that some may have them. Userspace apps really should never need to read your logs, you can see what permissions an app requires when you install it, this is the best way to manage permissions.
Hello, I was messing around a pair of friend's phones, both were asking me for the Viper4Android magic (root and everything) after achieve successfully both installs, I was unsatisfied, so I started to search and figure out how to up the volume level, I did it, the sound of that phones now was great and obviously I needed to do the same with my very own cellphone Le Max. I know it's not a necessary thing due the great volume level of our Le Maxs' but maybe someone need this, I am happy with the result.
1. You need a rooted Le Max
2. Install Total Commander (or similar)
3. Go to: system/vendor/CmccPower/system/vendor/
4. Find "power.prop" (make a backup for your security) and open it as a text
5. Go to the last line: "persist.audio.music.volume=5" and change 5 to 7 (to me 7 works fine)
6. Save and reboot.
* I can't tell if there is any difference from 1 to 5 values, in fact I hear the same (or almost the same) volume level, however at 7 I can notice a significative change, I can't explain why is that, I am just one of those eternal noobs populating XDA since years ago :silly:
Which rom is this for? On Omni 7 there is no such file/folder.
With a suitable kernel (eg Blackscreen) and Kernel Auditor you can go into Audio settings and increase Headphone Gain to ear-blistering levels if required.
popoyaya said:
Which rom is this for? On Omni 7 there is no such file/folder.
With a suitable kernel (eg Blackscreen) and Kernel Auditor you can go into Audio settings and increase Headphone Gain to ear-blistering levels if required.
Click to expand...
Click to collapse
I am in stock ROM