1) Драйвера
2) Драйвера для Windows 8
3) HTC One X+ All-in-One Toolkit V3.0
_{C другими можете ознакомится в теме "Прошивка"}

SENSE ядра

Такие ядра обычно идут в комплекте с прошивками, в которые не входит оболочка HTC Sense. Обычно это CM, AOSP, AOKP, OMNIROM и похожие прошивки.
Смысла выкладывать их тут не вижу.

1) EliteKernel OXP 4.1.1|4.2.2
2) SpeedyKernel

1) Ondemand:
Стандартный говернер в большинстве стоковых ядер (или ядер от Chainfire - прим. перевод). Основная цель данного регулятора - повышать частоту до максимальной как только появляется нагрузка на процессор, дабы обеспечить максимальную отзывчивость системы. Бесспорно, это эффективно - грубо говоря, каждый раз данный говернер ставит перед собой вопрос: насколько нагружен процессор и стоит ли мне повышать частоту? Итак, при обнаружении нагрузки на процессор ondemand говернер повышает частоту процессора до максимальной и постепенно понижает ее когда нагрузка спадает/пропадает вовсе. Даже несмотря на то, что большая часть пользователей считает данный говернер оптимальным, он никак не заботится о расходе вашей батарейки. Да, система с ним быстро работает, но зачастую (почти всегда) ресурсы процессора расходуются вхолостую.

2) Ondemandx:
В большинстве случаев - обычный ondemand с профилями для сна. Этот говернер представляет из себя чуть более щадящий ваш бесценный заряд батарейки ondemand. При выключенном дисплее максимальная частота процессора ограничивается 500МГц. Однако, несмотря на то, что обычный ондеманд является стандартным говернером в стоковых ядрах, ондемандх далеко не на всех аппаратах работает хорошо, ибо тут критична возможность процессора быстро реагировать на смену нагрузки и переход от профиля для сна в рабочий. Я однажды где-то прочитал, что работа данной версии говернера очень сильно меняется и зависит от i/o планировщика, однако для большинства ядер это не так. Лично мое мнение - лучше всего ондемандх работает с SIO I/O планировщиком.

3) Conservative:
"Медленная" версия ондеманд, крайне неохотно повышающая частоту процессора. При отсутствии нагрузки данный говернер использует минимально доступную частоту постоянно.

4) Interactive:
Если вкратце, то это более быстрый ондеманд. Намного быстрее, меньше батарейки. Ключевое отличие от ондеманда - говернер определяет нагрузку при выходе из режима сна и работает на заданной частоте большую часть времени до следующего "сна".

5) Interactivex:
Аналогично ондемандх - интерактив с профилем для "сна". Меньше расходует батарейку.

6) Lulzactive:
"Изобретен" пользователем с никнеймом Tegrak и основан на Interactive & Smartass governors и является одним из любимых.
Старая версия: когда нагрузка эквивалентна или приближена к 60%, говернер повышает частоту до следующей доступной частоты. Если же нагрузка меньше 60%, то частота понижается до следующей доступной планки. При отключенном дисплее частота останавливается на минимально доступной и не повышается.
Новая версия: имеет три новых параметра, доступных пользователю для настройки: inc_cpu_load, pump_up_step, pump_down_step. В отличие от старой версии, эта, как логично предположить, позволяет больше управлять работой говернера. Мы можем сами задать промежуток, в котором говернер будет решать, повышать или понижать частоту. Мы так же можем сами выбрать и настроить количество доступных частот, до которых говернер будет повышать/понижать работу процессора.
Когда нагрузка выше inc_cpu_load, говернер повышает CPU pump_up_step. Когда нагрузка ниже заданной в параметре inc_cpu_load, говернер понижает CPU pump_down_step.
Пример:
Consider
inc_cpu_load=70
pump_up_step=2
pump_down_step=1


7) Smartass:
Появился благодаря работе пользователя Erasmux, который целиком переписал код интерактив говернера, основной задачей была поставлена продолжительная работа от батарейки без потери производительности. Однако, не так хорош для заряда батареи нежели его преемник smartassV2.

8) SmartassV2:
Вторая версия оригинального смартэсс от Erasmux. Еще один любимец большинства. Говернер расчитан на работу на "идеальной частоте" и повышает частоту несколько более агрессивно, нежели понижает. Используются различные "идеальные" частоты для скрин-он и скрин-офф профилей, называются awake_ideal_freq и sleep_ideal_freq. Данный говернер понижает частоту очень быстро (дабы достичь той самой "идеальной частоты", прописанную в параметре sleep_ideal_freq как можно скорее) при выключенном дисплее и достаточно быстро повышает частоту при включенном дисплее дабы достич "идеальной" частоты awake_ideal_freq (500 mhz для SGS2 по умолчанию). Не имеет ограничения на максимальную частоту при отключенном дисплее (в отличии от оригинального Smartass). Мантра данного говернера - баланс между энергопотреблением и производительностью.

9) Intellidemand:
Intellidemand, так же известный как Intelligent Ondemand от пользователя Faux это, как несложно догадаться, еще один говернер, основанный на ондеманд. В отличии мнения большинства, данный говернер не влияет на OC Daemon (имеет различные профили для сна и скрин-он). Оригинальный интеллидеманд реагирует на нагрузку GPU. Когда графический чип уже под нагрузкой (игры, карты, бенчмарки и иже с ними), intellidemand начинает работать как ondemand. Когда же GPU 'спит' (или слабо нагружен), intellidemand ограничивает макимальную частоту в зависимости от частот доступных на вашем ядре/устройстве для сохранения батарейки - так называемый "browsing" режим. Прослеживаются некоторые следы интерактив говернера, не находите? Частота для повышения зависит от времени простоя CPU. Низкое время простоя (<20%) заставляет CPU повышать данную частоту (шаги примерно по 5% от максимально доступной частоты).
Подводя итог вышепереведенной белиберде, это оттвиканный ондеманд, который работает большую часть времени в browsing-режиме, сохраняя заряд вашей батарейки и переходящий в "рабочий" режим при получении нагрузки на графический чип, дабы улучшить производительность в играх и подобных им приложениях. Intellidemand не повышает частоту до максимально возможной при отключенном дисплее.

10) Lazy:
Этот говернер от Ezekeel (один из наиболее широко мыслящих разработчиков ядер - прим. перевод.) это, в большинстве своем, ондеманд с новым значением min_time_state, введеным для определения минимального времени, по прошествии которого CPU меняет частоту выше/ниже, в зависимости от нагрузки. Главная идея - исключить нестабильные постоянные скачки ондеманда.

11) Lagfree:
Лагфри похож на ондеманд. Основное отличие в оптимизации для улучшения энергопотребления. Частоты грациозно меняются, в отличии от ондеманда, который прыгает до 100% слишком часто. Лагфри не "перепрыгивает" через какие-либо доступные частоты при повышении или понижении нагрузки, потому вам стоит помнить, что при необходимости мгновенно получить максимальное быстродействие, данные говернер - не ваш выбор.

12) Lionheart:
Lionheart основан на conservative-версии говернера, который, в свою очередь, основан на samsung's update3 сорсах. Оттвикан был следующими пользователями: 1) Knzo 2) Morfic. Автор идеи: Netarchy. Смотрите здесь.

To 'experience' Lionheart using conservative, try these tweaks:sampling_rate:10000 or 20000 or 50000, whichever you feel is safer. (transition latency of the CPU is something below 10ms/10,000uS hence using 10,000 might not be safe).up_threshold:60down_threshold:30freq_step:5Лайонхарт хорошо работает с deadline i/o scheduler. В общем и целом по ощущениям это сравнимо с ондемандом при меньшем энергопотреблении (но куда как более высоком, нежели консерватив).

13) LionheartX
LionheartX основан на обычном лайонхарте, однако имеет профиль простоя от Smartass говернера.

14) Brazilianwax:
Аналогичен smartassV2. Чуть более агрессивно скейлит частоты, что выливается в чуть лучшую производительность и чуть меньшее кол-во времени работы.

15) SavagedZen:
Еще один основанный на smartassV2 говернер. В сравнении с бразиллианвакс предстает в лучшем свете из-за лучшего энергопотребления без потери производительности.

16) Userspace:
В отличии от всех перечисленных выше (и ниже) говернеров, позволяет целиком и полностью настроить его работу.

17) Powersave:
Понижает максимальную частоту до минимально доступной, тем самым потребляет очень мало энергии, но ваше устройство будет чудовищно лагать при нагрузке чуть более высокой, нежели минимальная (прим. перевод.).

18) Performance:
Работает с точностью да наоборот как паверсейв - устанавливает минимальную частоту на максимально доступную. Используйте для бенчмарков! (аппарат очень сильно греется, может зависнуть при долгой нагрузке)

Deadline
Deadline I/O Scheduler хранит отсортированную очередь, и вводит две дополнительные очереди: FIFO очередь на чтение и FIFO очередь на запись. Записи в каждой из этих очередей отсортированы по времени поступления (фактически, первый вошел -
первый вышел). Каждому запросу в очереди FIFO назначено время окончания. Для очереди запросов чтения - это 500 миллисекунд. Для очереди запросов записи - это пять секунд. При поступлении нового I/O запроса, он вставляется-сортируется в стандартную очередь и помещается в конец соответствующей (на чтение или запись) FIFO очереди.
Как правило, к жесткому диску посылаются запросы ввода/вывода с головы стандартной отсортированной очереди. Это максимизирует общую пропускную способность при минимизации операций поиска и установки головок на диске, так как нормальная очередь сортируется по номеру блока (как и с Linus Elevator). Когда у записи вначале списка одной из дополнительных FIFO очередей истечет назначенное время, I/O scheduler останавливает обработку I/O запросов из стандартной очереди, и начинает обслуживание запросов из этой FIFO очереди. I/O scheduler проверяет и обрабатывает запросы только с головы очереди, где находятся старейшие запросы.
Таким образом, Deadline I/O Scheduler поддерживает эффективную общую пропускную способность без голодания какого-либо одного запроса недопустимо длительное время. Проблема writes-starving-reads сводится к минимуму.

NOOP
Самый простой планировщик, обладает минимальными возможностями и выполняет только простые операции объединения и сортировки, но зато и потребляет минимум ресурсов. Он представляет собой очередь FIFO (First In, First Out) то есть он, просто выставляет запросы в очередь в том порядке, в котором они пришли. Предназначен NOOP в основном для работы с не дисковыми устройствами (ОЗУ или флэшдиск) или со пециализированными решениями которые уже имеют свой собственный планировщик I/O. В этом случае его простота имеет преимущество перед остальными алгоритмами.

CFQ (Completely Fair Queuing)
В CFQ каждому процессу присваивается собственная очередь, и каждой очереди присваивается квант времени (timeslice). Планировщик ввода/вывода по кругу обходит каждую очередь и обслуживает запросы из очереди до тех пор, пока не будет исчерпан лимит времени (timeslice) или не останется запросов в этой очереди. В последнем случае CFQ планировщик будет ждать, по умолчанию 10-мс, нового запроса из очереди. Если ожидание было напрасным, то планировщик переходит к следующей очереди.
В рамках каждой очереди процесса, синхронизированные запросы (как, например, читающие) имеют приоритет над несинхронизированными запросами. Таким образом, CFQ способствует чтению и предотвращает проблему writes-starving-reads.
CFQ планировщик хорошо подходит для большинства задач.
В ядрах 2.6.32 и новее можно немного повысить производительность на сервере путём отключения low latency , включенного по умолчанию, которое снижает пиковую производительность, но повышает отзывчивость, нужную только для десктопа.

Anticipatory
Проблема предыдущих планировщиков ввода/вывода вновь вытекает из зависимости: каждый новый запрос на чтение выдается только тогда, когда предыдущий будет возвращен, но к тому времени, когда приложение получает прочитанные данные и посылает следующий запрос на чтение, I/O планировщик уже начал обслуживание других запросов. В этом случае планировщик ввода/вывода в течении некоторого времени мог бы подождать поступление следующего запроса на чтение. Именно так и работает Anticipatory I/O Scheduler. Он основан на Deadline I/O Scheduler с добавлением механизма ожидания, до шести миллисекунд, следующего чтения. Если 6-ть миллисекунд истекли, но запроса на чтение не поступило, планировщик возвращается к работе, которую выполнял до этого (например, обслуживание стандартной отсортированной очереди).

BFQ (Budget Fair Queueing)
Планировщик BFQ создан как замена CFQ (и основан на его коде), основная мысль – более честное разделение I/O между процессами.
Работает планировщик отлично – тормоза GUI во время активной работы с диском фоновых процессов (например, загрузки виртуальной машины или обновления дерева portage) просто как рукой сняло.

SIO
SIO - это честный deadline планировщик. на текущий момент (по мнению автора ThunderBolt!) - это лучший планировщик (Однако в FuguMod 1980 его нет, не знаю как в других ядрах).
Более подробно: SIO - это простой планировщик ввода/вывода, в котором разработчики попытались внедрить в Noop систему обнаружения нехватки/истощения ресурсов. Следовательно, длительные IO транзакции будут получать процессорное время только после выполнения более быстрых транзакций (т е приоритет отдается быстрым транзакциям), что позволяет достичь гарантированной гладкости работы. Он не имеет накладных расходов и приоритизации транзакций, т е все транзакции (на чтение или на запись) равны.