DRAW_HOOK / Перехват фукции DrawObject
(с)Dimadze
(!)Чтобы всё полностью работало нужен ELFPAck 2.3 24bit+alpha или актуальная версия EP3!
V1.9

Доступно для:
-------------------------------------------
CX75v25
C75v22

SL65v53
CX70v56
S65v58
SK65v50
-------------------------------------------

ELFPack'и 2.3 24bit+alpha для SGold X65 можно взять отсюда \elfpacks\

Можно положить фулл VKP\MODELvFIRMWARE\FF.bin для автоматического вычисления старых данных для патча

Например:
MODELvFIRMWARE - SL65v53

Описание.
Патч, следит за функцией DrawObject(), через которую отрисовывается практически всё на Siemens,
т.е. когда параметр содержит указатель на 5ый объект отрисовки (`IMGHDR+RECT), патч проверяет
на альфа-канал, если его нет (bpnum!=0x0A), то всё отрисовывается стандартным образом, иначе
в дело вступает самописная ф-ия отрисовки, она сделана максимально оптимизированной.
В основе её работы лежит запись битмапа изображения прямо в промежуточный буфер отрисовки,
я назвал его RamScreenPhoneCache (есть аналогичный для Java) c вычислением цвета при альфа - канале.
В итоге на SGold X65 могут отрисовывться 32 битные (24bit+alpha) изображения в эльфах, а также менять
графику используя все 32 бита, а не 8 и 16.
Даже на CX75 видна разница, по стандарту видны "разводы", с патчем изображение рисуется совершенно чётко.
Скорость отрисовки с патчем и без по моим наблюдениям не меняеться.


Зачем на X65 нужен спецальный ELFPack.
Дело в том, что поддержку загрузки 32 битного битмапа из png на X65 спецально урезали в ELFPack 2.3,
так как телефон всё-равно не может его отрисовывать, зачем лишнее место занимать, правда же?
Но теперь телефон научился, и соответсвенно ему нужен ELFPack 24 bit + alpha.
 
Как портировать.
Проект настроен, и готов к компиляции.
Я уже сделал 3 конфигурации, SL65v53, CX70v56, S65v58

При портировании следует обратить внимание на эти 2 фаила в папке \config\:
 
 - MODELswFIRMWARE.xcl     (SL65v53.xcl)
 - drawhook.h

//MODELswFIRMWARE.xcl


PATCH_BODY,CODE ...  - это пустое место под тело патча 
PATCH_DRAWOBJECT_OBJ05 - адрес ф-ии подпрограммы DrawObject()
PATCH_DRAWOBJECT_OBJ17 - адрес ф-ии подпрограммы DrawObject()

И в дополнении для X75 надо:


PATCH_REPAIRJUMP145 - Место 8 байтного перехода на GBS_GetCurCepid 
PATCH_REPAIRJUMP100 - Место 8 байтного перехода на GBS_SendMessage 

PATCH_DRAWOBJECT_OBJ05_J32 - PATCH_REPAIRJUMP100 + 0x04 (дополнительное место для 32bit Branch'a)
PATCH_DRAWOBJECT_OBJ17_J32 - PATCH_REPAIRJUMP145 + 0x04 (дополнительное место для 32bit Branch'a)

PATCH_LOCALJUMP145 - Адрес GBS_GetCurCepid (0x145)
PATCH_LOCALJUMP100 - Адрес GBS_SendMessage (0x100)

//drawhook.h

Для X75:
#define EXC_CSM_MP - CSM Медиаплеера
#define EXC_CSM_ZP - CSM Функции Zoom


Ну а дальше искать ничего не нужно, но эту информацию я оставлю ...

Как искать RamScreenPhoneCache.
Для его нахождения открыть фулл в IDA, перейти на адрес ф-ии DrawObject
(берём из swilib.vkp, возможно их там будет несколько, берите любой).
Дизассемблим (THUMB), видем первую попавшуюся команду BL, переходим по ней, смотрим в окрестности,
находим команду LDR c загрузкой в регистр RAM-адреса, нашли?
Включаем ArmDebugger, переходим на этот адрес, видим указатель, дебаггер его выделит желтым,
переходим (просто нажимаем на него), теперь берём этот адрес (На CX75v25: 0xA84AE7B8)
и прибавляем к нему 0xAC (Ну это на CX75v25, а что у вас там я хз), получим 0xA84AE7B8+0xAC = 0xA84AE864.
Это и есть адрес того самого буфера. Если включить режим Monitor (M) в ArmDebugger,
и на телефоне поставить белую фон, белую заставку, что угодно, увидим массив байт 0xFF,
откуда он начался там и начальный адрес буфера.
Правда на SL65v53 я прибавил не 0xAC, а 0x1C5B4, вот так то ...

Ну или могу предложить вам следующий способ:
Отключаем overlay view (если он был и перерзагружаем телефон).
Включаем ArmDebugger переходим на RamScreenBuffer (0x0E0, берём с swilib.vkp),
и от начала буфера копируем байт 60. Теперь перейдём на 0xA8400000, 
И отсюда начинаем поиск этих 60 байт, при этом телефон дожен работать в одном этом же окне,
типа, если был на IDLE, то и дожен оставаться на IDLE до окончания поиска.
RamScreenPhoneCache он всегда до RamScreenBuffer (но и до RamScreenJavaCache, это тоже промежуточный буфер. но для Java)

Ну и, если вы не устали читать, то третий способ:
Поиск по паттерну Smelter'oм или вручную

Проверено на SL65/53, CX70/56, S65/58:
ADDR:char *RamScreenPhoneCache()=&(??,48,??,22,??,21,00,90,??,48,02,92,04,22,01,91,00,23,A4,38 ) // SGold X65
Проверено на С75/22, CF75/23, CX75/25:
ADDR:char *RamScreenPhoneCache()=&(??,49,??,22,??,48,02,92,04,22,00,23,0C,39,00,90 )             // SGold X75


История версий:
1.0 - Первая публичная версия
1.1 - Проведена небольшая оптимизация
1.2 - Добавлена поддержка автоперерисовки экрана

Оказывается, DrawObject после помещения обьекта в буффер сразу же перерисовывает экран, а моя спец - ф-ия,
естественно, это делать не умела, но если попутно с полупрозрачной картинкой рисовалась, например линия,
то экран благополучно бы перерисовался вместе с картинкой, но а если нет ничего, кроме альфа-картинки?
Правильно, рисовалась бы пустота, что мы и видели на примере эльфа Turnoff'a, поэтому решено в отрисовку
32-битной картинки вставить ма-а-а-ленький однобитный IMGHDR (1x1) и баг исчез.

1.3 - Перерисовка полупрозрачных изображений в текстовом поле

В текстовом поле, как мы знаем, должны быть символы, но а также есть возможность добавлять туда
картинки, то есть спецсимволы, зашифрованные как картинки, ну и поэтому в DrawObject приходили символы,
а не картинки, и перехват не работал, в итоге пустота. Но таки нашёл место, где они (картинки-символы)
приходят в "чистом" виде и там тоже установил перехват, ну и как вы догадались - картинки видны на экране.  

1.4 - Патч переписан по-другому, уменьшен размер патча, дополнительная автоперерисовка экрана больше не нужна.

1.5 - Ещё одна перестановка

Разгрузил врезки, оставил одну команду в каждой, т.е.  уменьшил лишний восстановительный код,
Добавлена поддержка полупрозрачности картинок в текстовом поле Java, теперь патч легко портируем,
т.е. надо найти врезки и всё, никаких дополнительных ROM/RAM адресов.
А также ведётся учёт глобальных границ отрисовки, т.е. картинка не вылезет туда куда нельзя. 
но врезки действителны в пределах +/- 4 Мб, поэтому на X75 никак не достанут до тела патча.
Да и впрочем, влезать в прошивку с таким "хирургическим" вмешательством - это не есть хорошо,
из плюсов: небольшое преимущество в качестве отрисовки, а из минусов - баги, лаги, раздербаненная
ф-ия DrawObject.

1.6 - Прорисовка полупрозрачных изображений в Java и иправлены некоторые баги

1.7 - Добавлена поддержка отрисовки 32х разрядного пакованного битмапа 0x8A

Дело в том, что алгоритм расшифровки RLE, на чём основана паковка битмапа, не полностью работает,
но пока нет для меня доказательств, что он не достаточен для полноценной отрисовки.
В любом случае буду искать более универсальные и оптимальные пути решения этой проблемы.

1.8 - Поправлена отрисовка 32х разрядного пакованного битмапа 0x8A

Теперь она работает на 100%, механизм RLE для пакованного битмапа 0x8A полностью поддерживаеться.
И эта ф-ия оснащена защитой от зависания, если ей дали неверно составленный битмап. 
Дело в том, что при неправельном исполнении битмапа, вся последовательность пикселей идёт наперекосяк,
это может вызвать многократное ложное считывание повторений и тогда отрисовка выходит далеко за пределы
битмапа в RAM'e. Ну и так как снежный ком, телефон так и будет заниматься этой отрисовкой - в итоге зависание.

1.9 - Немного упорядочен механизм отбора картинок, а также убирание глюка в медиаплеере на X75

Более тщательно изучил ф-ию DrawObject, а точнее, её механизм распределения отрисовок обьектов, не знаю
поможет это в скорости, но такой кашы в исходниках больше нет. Так ничто другого не придумав, убрать глюк
в медиаплеере на X75 пришлось огорождением Draw Hook от него, т.е от его CSM.