[Sprint HTC EVO 4G LTE] MikeC84:
FAQ's​

This will be updated regularly​

Why do I need to be s-off?

First off you should already be s-off if you are using any aosp rom. Second, s-off fixes many issues people come across when flashing roms.

Sense kernel will have SOn option.

Why do I only have two point multi touch with this kernel?

The synaptics 3k touch screen driver handles multiple touch events by default but do not work with htc gestures enabled. Go to Settings, Display, gestures & buttons, disable htc gestures and you will have more than two point multi touch.

Kernel Info​

Sweep2Wake

http://www.youtube.com/watch?v=jri2BMQHHrs

echo 0 > /sys/android_touch/sweep2wake (disable s2w)

echo 1 > /sys/android_touch/sweep2wake (enable s2w)

GPU Control

If you want to use kcontrol's gpu control without using kcontrol...

Paste this into a new document and name it '03GPU'

Follow the directions in the script to get the speeds

Paste the speeds in the insmod command according to the how to

Save and reboot

Governor Info

Lagfree

Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little. Sysfs included.

Smartass v2

Version 2 of the original smartass governor from Erasmux. Another favorite for many. The governor aims for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for GS2 by default) when screen is on. There's no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery. Sysfs included.

BadAss

Badass removes all of this "fast peaking" to the max frequency. On a typical system the cpu won't go above 918Mhz and therefore stay cool and will use less power. To trigger a frequency increase, the system must run a bit @ 918Mhz with high load, then the frequency is bumped to 1188Mhz. If that is still not enough the governor gives you full throttle. (this transition should not take longer than 1-2 seconds, depending on the load your system is experiencing)

Badass will also take the gpu load into consideration. If the gpu is moderately busy it will bypass the above check and clock the cpu with 1188Mhz. If the gpu is crushed under load, badass will lift the restrictions to the cpu.

Wheatley

Building on the classic 'ondemand' governor is implemented Wheatley governor. The governor has two additional parameters:

target_residency - The minimum average residency in µs which is considered acceptable for a proper efficient usage of the C4 state. Default is 10000 = 10ms.

allowed_misses - The number sampling intervals in a row the average residency is allowed to be lower than target_residency before the governor reduces the frequency. This ensures that the governor is not too aggressive in scaling down the frequency and reduces it just because some background process was temporarily causing a larger number of wakeups. The default is 5. Wheatley works as planned and does not hinder the proper C4 usage for task where the C4 can be used properly .

For internet browsing the time spend in C4 has increased by 10% points and the average residency has increased by about 1ms. I guess these differences are mostly due to the different browsing behaviour (I spend the last time more multi-tabbing). But at least we can say that Wheatley does not interfere with the proper use of the C4 state during 'light' tasks. For music playback with screen off the time spend in C4 is practically unchanged, however the average residency is reduced from around 30ms to around 18ms, but this is still more than acceptable. So the results show that Wheatley works as intended and ensures that the C4 state is used whenever the task allows a proper efficient usage of the C4 state. For more demanding tasks which cause a large number of wakeups and prevent the efficient usage of the C4 state, the governor resorts to the next best power saving mechanism and scales down the frequency. So with the new highly-flexible Wheatley governor one can have the best of both worlds.

Obviously, this governor is only available on multi-core devices.

I/O Scheduler Info

Noop

Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.

Advantages:

Serves I/O requests with least number of cpu cycles. (Battery friendly?)

Best for flash drives since there is no seeking penalty.

Good throughput on db systems.

Disadvantages:

Reduction in number of cpu cycles used is proportional to drop in performance.

Deadline

Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.

Advantages:

Nearly a real time scheduler.

Excels in reducing latency of any given single I/O.

Best scheduler for database access and queries.

Bandwidth requirement of a process - what percentage of CPU it needs, is easily calculated.

Like noop, a good scheduler for solid state/flash drives.

Disadvantages:

When system is overloaded, set of processes that may miss deadline is largely unpredictable.

CFQ

Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.

Advantages:

Considered to deliver a balanced i/o performance.

Easiest to tune.

Excels on multiprocessor systems.

Best database system performance after deadline.

Disadvantages:

Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.

Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.

BFQ

Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.

Advantages:

Believed to be very good for usb data transfer rate.

Believed to be the best scheduler for HD video recording and video streaming. (because of less jitter as compared to CFQ and others)

Considered an accurate i/o scheduler.

Achieves about 30% more throughput than CFQ on most workloads.

Disadvantages:

Not the best scheduler for benchmarking.

Higher budget assigned to a process can affect interactivity and increased latency.

SIO

Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.

Advantages:

Simple, so reliable.

Minimized starvation of requests.

Disadvantages:

Slow random-read speeds on flash drives, compared to other schedulers.

Sequential-read speeds on flash drives also not so good.

ROW

The ROW I/O scheduler gives priority to READ requests over the WRITE requests when dispatching, without starving WRITE requests. Requests are kept in priority queues. Dispatching is done in a RR manner when the dispatch quantum for each queue is calculated according to queue priority.

Most suitable for mobile devices.