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
Related
The HTC Evo has an additional LED (turquoise / red) on the right of the headset speaker. This is being implemented by using the Jogball I2C interface that is also found on their "trackball" phones except this phone has some preset modes.
You can talk with the LED directly by going through shell:
# echo 1 > /sys/class/leds/wimax/brightness
Current "brightness" modes it supports
1 = Two quick turquoise flashes
2 = One quick turquoise flash
3 = One slow turquoise flash
4 = One slow turquoise flash then one slow red flash
5 = One slow yellow flash
129 = Solid red on
130 = Solid turquoise on
131 = Solid yellow on
I am interested in getting the additional LEDs on the EVO to do something useful. In particular I would like to get the other LED possibly tied into the current CM6 ledARGB functinality that Cyanogen/Pedlar are working on. Obviously we would have a different / limited color range, but at least we would have more notification options with screen off.
*Original Post - Deprecated*
I was wondering what the general consensus is on a design for the /sys/devices/platform/leds-microp/leds objects for a change to the kernel.
The EVO has two dual color leds at the top.
- A. Green / Amber (left side of speaker)
- B. Cyan(turquoise) / Red (right side of speaker)
The current drivers put those at:
A(green) = ./green/brightness
A(amber) = ./amber/brightness
B(cyan/red) = none (only accessible by setting various ./wimax/blink modes from what I can tell)
Proposal:
-- existing --
A(green) = ./green/brightness
A(amber) = ./amber/brightness
B(cyan/red) = (leave the existing ./wimax nodes intact for backward compat)
-- new --
B(cyan) = ./cyan/brightness
B(red) = ./red/brightness
B(cyan/red) = ./argb/? (would like to create a similar looking node system to other phones containing either the Trackball LED or aRGB LED)
Essentially I am looking for comments/criticisms on the proposed structure and information on what the N1 trackball / Droid aRGB node structures look like (in order to be consistent)
If you are talking about the WiMAX LED it only has two colors: green and red. I am working on an app that will exploit this to use it for SMS and other notifications.
bludragon742 said:
If you are talking about the WiMAX LED it only has two colors: green and red. I am working on an app that will exploit this to use it for SMS and other notifications.
Click to expand...
Click to collapse
Yes, I am talking about the LED that uses the "./wimax" node (B). The green is kinda a blueish green, so I just called it cyan in order to avoid conflict with the other 'green' led. HTC's kernel interface appears lacking/inconsistent and I wanted to "complete" it by creating the cyan / red elements.
Just adding some additional information here.
It would appear that the Wimax LED is controlled via I2C with the following code in leds-microp.c. Does anyone know more about the the protocol of this? Im trying to see if I can control the two LEDs brightnesses / frequency independently.
Apparently (0-5,129, 130,131 are special modes on that device): 1-5 = pulses of various sorts, 129 = solid red, 130 = solid green, 131 = both (makes yellow) .
switch (brightness) {
case 0:
data[0] = 0;
break;
case 1:
case 2:
case 3:
case 4:
case 5:
case 129:
case 130:
case 131:
data[0] = brightness;
data[1] = data[2] = 0xFF;
break;
default:
pr_warning("%s: unknown value: %d\n", __func__, brightness);
break;
ret = microp_i2c_write(MICROP_I2C_WCMD_JOGBALL_LED_MODE, data, 3);
Wow thanks for the extra values! I'll put them to use in my program! Where did the source code you posted come from? I might want to take a look at it as it could make my job easier.
bludragon742 said:
Wow thanks for the extra values! I'll put them to use in my program! Where did the source code you posted come from? I might want to take a look at it as it could make my job easier.
Click to expand...
Click to collapse
Download the kernel source (ToastCFH's repo on GitHub is the best source) and look in /arch/arm/mach-msm and there'll be a bunch of c files there.
I think the LED code is in leds-microp.c but I'm not sure. Someone posted it earlier but I'm too lazy to look
here's the whole folder genius dog was talking about. I hope we can get more progress out of this. I wanna use that WIMAX led.
Awesome thanks!
bludragon742 said:
Awesome thanks!
Click to expand...
Click to collapse
Also........
david279 said:
here's the whole folder genius dog was talking about. I hope we can get more progress out of this. I wanna use that WIMAX led.
Click to expand...
Click to collapse
I saw that Cyanogen added the Wimax LED node to the Liblights on CM6. Nothing has been implemented on the UI yet to use it though (AFAIK)
http://github.com/CyanogenMod/android_hardware_msm7k/commit/4c19a2bc7cdbaa5098802c3a732ec4f37ebe530c
Hopefully Bluedragon will get us a Blink like app! Im going to try and take a stab working with someone on the CM team to get it implemented there as well.
The more I think about it, the modes that are already present on I2C driver are probably more than adequate for notification needs. Trying to change the mix of colors on just two LEDs would be hard to distinguish anyway. It would be nice to change the frequency of the light flashing though and am still looking into that.
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.
NOTE: The first six posts are a reply to the old post that I removed long ago.
I shouldn't have removed it completely.
Click to expand...
Click to collapse
This is the current configuration of the touchscreen:
Code:
=========== [TSP] Configure SET for normal ============
=== set_power - GEN_POWERCONFIG_T7 ===
0. idleacqint= 64, 1. actvacqint=255, 2. actv2idleto= 50
=== set_acquisition - GEN_ACQUIRECONFIG_T8 ===
0. chrgtime= 10, 1. reserved= 0, 2. tchdrift= 5
3. driftst= 1, 4. tchautocal= 0, 5. sync= 0
6. atchcalst= 9, 7. atchcalsthr= 27
=== [COLOR="Green"][B]set_touchscreen[/B][/COLOR] - TOUCH_MULTITOUCHSCREEN_T9 ===
0. ctrl=143, 1. xorigin= 0, 2. yorigin= 0
3. xsize= 18, 4. ysize= 11, 5. akscfg= 1
6. blen= 16, 7. tchthr= 32, 8. tchdi= 2
9. orientate= 1, 10.mrgtimeout= 0, 11.movhysti= 3
12.movhystn= 1, [COLOR="Red"][B]13[/B][/COLOR][B].movfilter= [/B][COLOR="Blue"][B]46[/B][/COLOR], 14.numtouch= 5
15.mrghyst= 5, 16.mrgthr= 40, 17.tchamphyst= 10
18.xrange=799, 19.yrange=479, 20.xloclip= 0
21.xhiclip= 0, 22.yloclip= 0, 23.yhiclip= 0
24.xedgectrl= 0, 25.xedgedist= 0, 26.yedgectrl= 0
27.yedgedist= 0, 28.jumplimit= 18
=== set_keyarray - TOUCH_KEYARRAY_T15 ===
0. ctrl=131, 1. xorigin= 16, 2. yorigin= 11
3. xsize= 2, 4. ysize= 1, 5. akscfg= 1
6. blen= 0, 7. tchthr= 45, 8. tchdi= 4
=== set_grip - PROCI_GRIPFACESUPRESSION_T20 ===
0. ctrl= 19, 1. xlogrip= 0, 2. xhigrip= 0
3. ylogrip= 5 4. yhigrip= 5, 5. maxtchs= 0
6. reserved= 0, 7. szthr1= 30, 8. szthr2= 20
9. shpthr1= 4 10.shpthr2= 15, 11.supextto= 10
=== set_noise ===
0. ctrl = 135, 1. gcaful(2bts)=0
2. gcafll(2bts)= 0, 3. actvgcafvalid =3
4. noisethr= 27, 5.freqhopscale= 0,6. freq[0]= 29
7. freq[1]= 34, 8. freq[2]= 39, 9. freq[3]= 49
10.freq[4]= 58, 11.idlegcafvalid= 3
=== set_total ===
0 , linearization_config.ctrl = 0
1 , twotouch_gesture_config.ctrl = 0
2 , onetouch_gesture_config.ctrl = 0
3 , selftest_config.ctrl = 0
4. cte_config.ctrl= 0, 5. cte_config.cmd= 0
6. cte_config.mode= 2, 7. cte_config.idlegcafdepth= 16
8. cte_config.actvgcafdepth= 63, 9.cte_config.voltage= 60
================= end ======================
To change it you simply need to run few commands:
Code:
echo [COLOR="Red"][B]13[/B][/COLOR][COLOR="Blue"]0[B]46[/B][/COLOR] > /sys/touchscreen/[COLOR="Green"][B]set_touchscreen[/B][/COLOR]
XX is the number of the option. In this example 13=movfilter.
YYY is the value you want to set. In this case 46. You must use 3 digits.
set_touchscreen is the file where you store this information. It's not always set_touchscreen, it could also be set_noise, set_acquisition etc...
To apply the changes you have to run this:
Code:
cat /sys/touchscreen/set_write
To get the new configuration run
Code:
dmesg
This will output a lot of kernel messages, not only the touchscreen configuration.
If you want to get the default configuration: reboot, 'cat /sys/touchscreen/set_write' and then 'dmesg'.
That's it.
Here some values explained: http://pastebin.com/raw.php?i=WSqjYT2t
Here a script with the default values, you can use it as base: http://pastebin.com/CejX00v5
The changes are not permanent, they are resetted on every boot. If you do something wrong, you can always reboot.
Don't put anything untested in /etc/init.d/
====
Here a i9000 script adapted for our phone.
Code:
#!/system/bin/sh
#Touchscreen
#Configure touchscreen sensitivity
#Sensitive(Chainfire)
echo 7035 > /sys/touchscreen/set_touchscreen;
echo 8002 > /sys/touchscreen/set_touchscreen; #default setting
echo 11000 > /sys/touchscreen/set_touchscreen;
echo 13060 > /sys/touchscreen/set_touchscreen;
echo 14005 > /sys/touchscreen/set_touchscreen; #default setting
cat /sys/touchscreen/set_write;
Default values (you can also reboot the phone):
Code:
#!/system/bin/sh
#Touchscreen
#Configure touchscreen sensitivity
#Sensitive - default settings
echo 7032 > /sys/touchscreen/set_touchscreen;
echo 8002 > /sys/touchscreen/set_touchscreen;
echo 11003 > /sys/touchscreen/set_touchscreen;
echo 13046 > /sys/touchscreen/set_touchscreen;
echo 14005 > /sys/touchscreen/set_touchscreen;
cat /sys/touchscreen/set_write;
___________
Note
In different custom roms I saw this:
Code:
#!/system/bin/sh
#Touchscreen
#Configure touchscreen sensitivity
#Sensitive(Chainfire)
echo 7035 > /sys/class/touch/switch/set_touchscreen;
echo 8002 > /sys/class/touch/switch/set_touchscreen;
echo 11000 > /sys/class/touch/switch/set_touchscreen;
echo 13060 > /sys/class/touch/switch/set_touchscreen;
echo 14005 > /sys/class/touch/switch/set_touchscreen;
This script obviously is not for our phone, it doesn't work.
The touchscreen maximum scan speed of the AT42QT602240 it's 250Hz for 1 finger (one scan every 1/250 s --> 4ms per scan)
so it will always have delay while moving, maybe you can improve it to some extent but it's slow compared to rapid movements that can be made while drawing, but for normal use, it isn't noticeable.
More info about scanning speed results:
http://www.youtube.com/watch?v=vOvQCPLkPt4
i think MOVHYSTI it's there on purpose to prevent some unintentional rubbing.
You are right, thanks for the explanation.
I knew it was there for a reason, but I still prefer as it is now. As you said, it's ok for normal use, playing games it's harder now.
Edit: with the original movfilter value, games are not that bad (I only tried Angry Birds), not that I care that much
I also want to add that the controller chip 4ms isn't final, the response that the microsoft research team it's showing it's for the whole loop (finger detected > drawed point on screen) and for that a lot of other times are need to take in account, for example screen refresh rate of our device (and most) takes about 17ms (60hz), so there is a need to improve hardware on the forthcoming devices.
this problem has been solved in ddkp3 version of indian firmware ! cus when i try doin this it moves instantly ! or is it cus of vurrut kernel ? i dono but the touchscreen is working great for me
Negative
I am on MIUI.
I tried your test.
But my screen moved instantaneously.
Probably I didn't explain what I mean well enough. Let's try this:
Put your finger on the screen and try to move it changing the coordinates of a single digit, not three, not five, just one. It's better if you do this in a single direction, try to keep still the X or the Y.
I doubt you can do this. And do this right after you put the finger on the screen, not after the coordinates already changed, becase after that the hysteresis automatically changes.
I know the change is instant even without this patch, I'm not talking about centimeters, inches (or whatever you use) and it's not to be intended in terms of time. I'm talking about pixels. This change is nothing revolutionary, we can't improve our hardware. Moreover the value that make me feel the change was movfilter, but in some situations the screen was hard to use, so I put back the original value.
I'm suggesting to remove the hysteresis because I think that every app applies a sort of movement filter that is coupled with it. With the updated values I can easly keep the screen still with my finger on it (with the first ones there were some microscillations).
Does anyone know why the screen sensitivity changes while plugged in?
The TSP thresold is intentionally increased, I don't want to change this, it's just a curiosity, because I couldn't find any exhaustive explanation.
I added two scripts (read the OP).
@rom cooks:
This is especially for you. Read the note in the first post.
How did you get the first configuration file ??
how can I view the current configuration ??
what do this improvement does ?
is it multitouch?
what is movfilter ???
vivekkalady said:
How did you get the first configuration file ??
how can I view the current configuration ??
Click to expand...
Click to collapse
Oh, I forgot to add this info.
Code:
cat /sys/touchscreen/set_write
dmesg
The first command set the current configuration and then use printk() to show it. To see "printk()" messages, you have to use the second command (dmesg). This will print a lot of kernel messages, not only the touchscreen configuration.
vivekkalady said:
what do this improvement does ?
Click to expand...
Click to collapse
It's like changing brightness/colours of your screen. There's no real improvement, it's up to you. I showed you a way to configure your touchscreen.
is it multitouch?
Click to expand...
Click to collapse
I don't understand what you mean.
You can change the number of finger tracked by the screen if you want (default 5, numtouch).
vivekkalady said:
what is movfilter ???
Click to expand...
Click to collapse
A parameter I used in the example above.
If you want to know what's its effect, well, try to change it.
Basically it changes how the screen reacts to movements. If you set it to a very low value, scrolling becomes very hard, the screen is like immovable.
I have problems scrolling trough homescreens. Sometimes I have to move my finger across the screen 3 times to scroll. And sometimes I want to scroll and accidentaly open an app. I hate it, I tried every rom and the only one that partially solve this was Cranium. I think this happend because the procesor have other priorities (conect wifi, download data package, send sms, etc) over the touchscreen.
juanmaper said:
I have problems scrolling trough homescreens. Sometimes I have to move my finger across the screen 3 times to scroll. And sometimes I want to scroll and accidentaly open an app. I hate it, I tried every rom and the only one that partially solve this was Cranium. I think this happend because the procesor have other priorities (conect wifi, download data package, send sms, etc) over the touchscreen.
Click to expand...
Click to collapse
ur touchscreen is probably DIRTY or has sum oily liquids on it ! clean it with a soft wet cloth several times and it'll go away ! i had that isue before
shriomman said:
ur touchscreen is probably DIRTY or has sum oily liquids on it ! clean it with a soft wet cloth several times and it'll go away ! i had that isue before
Click to expand...
Click to collapse
No dude, its a soft problem. Thanks anyway.
juanmaper said:
I have problems scrolling trough homescreens. Sometimes I have to move my finger across the screen 3 times to scroll. And sometimes I want to scroll and accidentaly open an app. I hate it, I tried every rom and the only one that partially solve this was Cranium. I think this happend because the procesor have other priorities (conect wifi, download data package, send sms, etc) over the touchscreen.
Click to expand...
Click to collapse
So this happens while you are doing other things, right?
If it's not because of some dirty on the screen, the only suggestions I could give you are:
try to change CPU governor
try to change I/O scheduler
try to convert your partitions in ext4 (Cranium used it if I'm not wrong)
See if this can help: http://forum.xda-developers.com/showthread.php?t=1137554
loSconosciuto said:
So this happens while you are doing other things, right?
If it's not because of some dirty on the screen, the only suggestions I could give you are:
try to change CPU governor
try to change I/O scheduler
try to convert your partitions in ext4 (Cranium used it if I'm not wrong)
See if this can help: http://forum.xda-developers.com/showthread.php?t=1137554
Click to expand...
Click to collapse
Im using lulzactive, and is a little more smoother, but time to time it happend that cannot scroll well.
loSconosciuto said:
Does anyone know why the screen sensitivity changes while plugged in?
The TSP thresold is intentionally increased, I don't want to change this, it's just a curiosity, because I couldn't find any exhaustive explanation.
Click to expand...
Click to collapse
+1. When plugged in the phone is really smooth.
I am also having the same problem... Especially in Swype keyboard... I think its a sensitivity problem...btw... Does a screen protector decreases or interfere with the sensitivity of the screen...?
landono5 said:
Does a screen protector decreases or interfere with the sensitivity of the screen...?
Click to expand...
Click to collapse
I don't know, I've never used one, but it's not unlikely.
You can increase the sensitivity with:
Code:
echo 7025 > /sys/touchscreen/set_touchscreen
cat /sys/touchscreen/set_write
Try different values.
If you go below ~10 your finger is detect even if you don't touch the screen. I suggest you not to use too low values here. (default=32)
landono5 said:
I am also having the same problem... Especially in Swype keyboard... I think its a sensitivity problem...btw...
Click to expand...
Click to collapse
I had problems with swype too. I had lags especially when the "suggestions bar" appeard/disappeared. Try this:
Swype settings->Word suggestion->tick everything
In this way it's less probable that the "suggestion bar" disappears.
Now, after a clean wipe and some tweaks, this problem seems almost gone and the setting I suggested does nothing in my case, but you can try.
landono5 said:
I am also having the same problem... Especially in Swype keyboard... I think its a sensitivity problem...btw... Does a screen protector decreases or interfere with the sensitivity of the screen...?
Click to expand...
Click to collapse
I have a screen protector and it doesnt interfere with the sensitivity. I think it depends on the protector. I have a cheap one, and its ok.
loSconosciuto said:
I don't know, I've never used one, but it's not unlikely.
You can increase the sensitivity with:
Code:
echo 7025 > /sys/touchscreen/set_touchscreen
cat /sys/touchscreen/set_write
Try different values.
If you go below ~10 your finger is detect even if you don't touch the screen. I suggest you not to use too low values here. (default=32)
I had problems with swype too. I had lags especially when the "suggestions bar" appeard/disappeared. Try this:
Swype settings->Word suggestion->tick everything
In this way it's less probable that the "suggestion bar" disappears.
Now, after a clean wipe and some tweaks, this problem seems almost gone and the setting I suggested does nothing in my case, but you can try.
Click to expand...
Click to collapse
Low values consume more battery, right?
juanmaper said:
Low values consume more battery, right?
Click to expand...
Click to collapse
I don't know, I use a value similar to the stock one. I put low values once for testing purpose only.
I suggested not to go below 10 because the touchscreen becomes almost unusable, it does things by itselfs.
loSconosciuto said:
I don't know, I use a value similar to the stock one. I put low values once for testing purpose only.
I suggested not to go below 10 because the touchscreen becomes almost unusable, it does things by itselfs.
Click to expand...
Click to collapse
I think the problem is not the sensitivity, its the number of times that the screen refresh the position of the finger. Because when I touch the screen just a bit, it work. But when trying to scroll, sometimes it dont.
Dear guys and gals,
Found a key for touch prediction that when edited showed a marked improvement in keyboard responsiveness and small item manipulation ie classic desktop, file explorer, etc.
The key is: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\TouchPrediction
Edit key for latency from 8 to 2.
Edit sample time from 8 to 2
Restart
See attached for a edited registry key to inject. Tested on two surfaces with no ill effects.
edit: to answer a few questions: this increases performance on all touch aspects of the device
The most likely ill effect would be a decrease in battery life as the system must poll the touchscreen more often... just be aware. Otherwise, cool find.
Keyboard does seem faster... Does this also affect swiping? it seems like I can swipe in any way and get the full length of the page / app in one swipe?
Haven't noted in marked increase in battery consumption but I will monitor.
Could this improve the home key button, when my surface is on standby it takes about 6 taps to get the surface to wake up.
possibly, I have not tested the mod for that per say,
Dane Reynolds said:
Could this improve the home key button, when my surface is on standby it takes about 6 taps to get the surface to wake up.
Click to expand...
Click to collapse
I also have not noticed an increase in battery usage on my asus vivo tab. Not a surface, but rt.
What would decreasing the values to 1 due? I am assuming the lower the value, the better. Or did it not test well on Surface?
Originally I choose 2 to test the battery draw. However, now that I haven't seen any significant increase in battery usage the drop to 1 can be done.
Dadstar said:
What would decreasing the values to 1 due? I am assuming the lower the value, the better. Or did it not test well on Surface?
Click to expand...
Click to collapse
Is it that easy for all the values? In other words, can all of the registry values be set to 1 to improve performance? Or are all the values a certain number for a reason? Cuz if latency of 1 works better than the original 8, idk why Microsoft would put it at 8 in the first place. Sorry for all the questions. This stuff is interesting to me!
First off all any values are "safe values". Some screens might be of worse quality then others (different manufacturers of parts). Having that value setup to happy medium means all screens act the same. You lower the value you demand that screen reads the inputs faster and more often. Might not be a good idea on some devices.
Not only talking about surface. Remember win8 (especially pro) will go on many different devices.
Also if you set sampling and refresh to low it might start having ghost touches from minimum input that would normally not be visible (oversensitive).
Best to practice and find perfect for you and your device.
ruscik said:
First off all any values are "safe values". Some screens might be of worse quality then others (different manufacturers of parts). Having that value setup to happy medium means all screens act the same. You lower the value you demand that screen reads the inputs faster and more often. Might not be a good idea on some devices.
Not only talking about surface. Remember win8 (especially pro) will go on many different devices.
Also if you set sampling and refresh to low it might start having ghost touches from minimum input that would normally not be visible (oversensitive).
Best to practice and find perfect for you and your device.
Click to expand...
Click to collapse
How about the other regs that don't really have a highest/lowest rate? For example, Disable Hotmail is defaulted at 2. What would changing that to 1 do?
Dadstar said:
How about the other regs that don't really have a highest/lowest rate? For example, Disable Hotmail is defaulted at 2. What would changing that to 1 do?
Click to expand...
Click to collapse
No there is no general rule where lower value is better. Some of the values displayed are "face values" where 2 is 2 like refresh 2 times a second. Some times 2 and 1 have a meaning off or on (like your hotmail). Remember PC reads numbers. Even more sometimes numbers, text or mix you see like 8 or 4 are actually representations of some kind of code for example hex or binary.
If you do not know what the number represents then changing it is a guess and nothing more. Just have a backup copy as fiddling in registry with drivers can have funny side effects. I did make my hd7 think i am touching it everywhere all the time so it hang seconds after boot
Are we sure this does anything at all? In order to test if the differences were psychological, I set the number to a ridiculously high value and it didn't seem to behave any differently.
Yup I found noticeable differences in fine touch control including in the registry,window control, etc.
Wupideedoo said:
Are we sure this does anything at all? In order to test if the differences were psychological, I set the number to a ridiculously high value and it didn't seem to behave any differently.
Click to expand...
Click to collapse
Thanks a lot!
Is 2 a good value in the case of the surface PRO 1 ?
"touch prediction" did prediction, not pooling!
"Latency" = how much milisecond to look ahead
"SampleTime" = the period in milisecond to average your finger's motion
The effect is thus:
Larger "latency" make the pointer overshoot, smaller "latency" make the pointer lag behind (1 - 100 milisecond depending on your system performance).
There's no penalty on your tablet's battery or digitizer's life for turning TouchPrediction off, and you don't need to restart to see the effect. (try finger drawing in MS Paint to see effect)
If your Surface missed touch, then try to cool the back of your tablet. It might be thermal throttling.
Im starting this thread for anyone having the same issue as me where by adding the property ro.config.media_vol_steps to /system/etc/prop.default and assigning their prefered steps value, ie '= 30', results in multiple volume ranges devisable by 15.
Apparently this affects the HTC UI sense as well.
For example if I assign the value 37 to the above property (I do get 37 steps) but when I test by playing something on spotify and increase volume using the buttons I get -
step 0 = mute
step 15 = max volume
step16 = mute
step 30 = max volume
step 31 = mute
step 37 = volume 6
Anything below 15 works as expected.
The same happens if you've rooted with Magisk and do it via prop editor or any other editor.
Iv been trying to find a solution for this for months with no success hence up the creek with no paddle.
I have coding abilities but for me X86 assembly is easier than than understanding the various tool chains / libraries / compilers required to debug an Android device.
Id like to at least know where in the architecture I should be focusing on.
Is it vendor or system related?
A persistant setting?
Is the setting pre compiled so would need custom ROM ie a library file (.so) where other devices simply allow to change the property?
I beleive it must be solvable just hoped I could get at least a hyperthetical view of the problem from someone more familiar with the sourcery of Android!
You can get fine volume control from the GUI (swipe down) how can this be mapped to Volume_key_up / volume_key_down ?
Thanks.