[TouchPad Development] CDMoncrieff:
Rationale: Save power while sleeping

+wifi.supplicant_scan_interval=180 (reduce time WiFi spends searching while disconnected)

Rationalle: Increase UI experience

+# various performance tweaks

+debug.performance.tuning=1 (increase touch responsiveness, not sensitivity)

+video.accelerate.hw=1 (increase touch responsiveness, not sensitivity)

+persist.sys.use_dithering=0 (disable surface dithering to free up system resources)

+ro.home_app_adj=1 (keep launcher in memory for smoothness)

+net.tcp.buffersize.wifi=4096,87380,256960,4096,163 84,256960 (increase WiFi buffer for faster WiFi)

+dalvik.vm.execution-mode=int:jit (use the Just In Time dalvik compiler to free up resources and increase speed)

+com.qc.hardware=true (add UI smoothness for Qualcom devices)

I had to coment out backuptool in tenderloin_ota_from_target_files because it was stopping the build from completing in AOKP. I usually add it back in the updater script and /bin (post compiled) from CM10.1. I am also considering commenting out in-line building of ramdisk.ub and boot.img in uboot-bootimg.mk because they result in an build error also (bin/bash: A: is not a command). But, I am not sure if this is just my build environment, or a problem with multiboot.

INTERNAL_UMULTIIMAGE_ARGS := --A arm -O linux -T multi -C none -n "$(INTERNAL_UBOOT_MULTIIMAGENAME)"

&

INTERNAL_URAMDISKIMAGE_ARGS := -A ARM -O Linux -T RAMDisk -C none -n "$(INTERNAL_UBOOT_IMAGENAME)" -d $(BUILT_RAMDISK_TARGET)

Which can instead be build manually with:

mkimage -A ARM -O Linux -T RAMDisk -C none -n "CM-.. tenderloin Ramdisk" -d /home/***pathto***/aokp/out/target/product/tenderloin/ramdisk.img /home/***pathto***/aokp/out/target/product/tenderloin/ramdisk.ub

&

mkimage -A arm -O linux -T multi -C none -n "CM-.. tenderloin Multiboot" -d /home/***pathto***/android/aokp/out/target/product/tenderloin/kernel:/home/***pathto***/aokp/out/target/product/tenderloin/ramdisk.ub /home/***pathto***/aokp/out/target/product/tenderloin/boot.img

I am experimenting with the ts_srv.c at the moment, by increasing "device.absmin[ABS_MT_PRESSURE] =" up to 450, the touch issue improves but the overall touch experience decreases. Rather than copying that commit, consider what the effect of this one was: https://github.com/CyanogenMod/andr...mmit/1459cfe63c80211fc9593685d388b8c3a0723389

And take a look at these lines of ts_srv.c

// Any touch above this threshold is immediately reported to the system

#define TOUCH_INITIAL_THRESHOLD 32

int touch_initial_thresh = TOUCH_INITIAL_THRESHOLD;

// Previous touches that have already been reported will continue to be

// reported so long as they stay above this threshold

#define TOUCH_CONTINUE_THRESHOLD 26

int touch_continue_thresh = TOUCH_CONTINUE_THRESHOLD;

// New touches above this threshold but below TOUCH_INITIAL_THRESHOLD will not

// be reported unless the touch continues to appear. This is designed to

// filter out brief, low threshold touches that may not be valid.

#define TOUCH_DELAY_THRESHOLD 28

int touch_delay_thresh = TOUCH_DELAY_THRESHOLD;

// Delay before a touch above TOUCH_DELAY_THRESHOLD but below

// TOUCH_INITIAL_THRESHOLD will be reported. We will wait and see if this

// touch continues to show up in future buffers before reporting the event.

I thought the changes to tenderloin_android_defconfig in the kernel by jcsullins to reduce the risk of battery related bricking were brilliant, and decided to bump it uo to 6% because of the power drain issues that are currently present. Increasing the 3D clock to 320MHz and 2D to 270MHz only makes a difference of a few FPS, but I do it anyhow!

Also, thanks for making your Repo known! It really was the kick start to 4.2.2 development!

:D