[Nexus 4 Original Android Development] mrg666:
Recommendations:

I am frequently receiving requests to add sound patches in the kernel. I agree that the sound is not very good but there are solutions. I am using the Viper4AndroidFX as a replacement sound processor. I recommend giving it a try. You need to go to the sound options and select ViPER4AndroidFX to use this sound processor or freeze MusicFX (I use Link2SD for this). There is plenty of information at the above link. With this available, I am not planning to add any sound patches.

Another frequent question is about choosing CPU governor and IO scheduler. In the earlier builds, interactive governor had the best balance of performance and battery life among other CPU governors and it is still available. In the latest builds, ondemand governor was backported from Linux 3.12 and replaced interactive as the default. The latest patches in the mainline Linux, especially stratosk's patch that optimized the load calculations made the new ondemand governor the better option regarding both power and performance. Regarding IO scheduler, BFQ scheduler has the best overall real-use performance and it is actively maintained/improved. You can use Nofrills CPU Control to change the governor and scheduler. But I would leave the defaults as BFQ scheduler and ondemand governor.

Since all of the cpu power control functions are contained in the kernel with MiRaGe, the userspace PowerHAL library will be giving the following messages in the logcat.

E/PowerHAL( 511): touch_boost: failed to send: No such file or directory
E/PowerHAL( 511): touch_boost: failed to send: No such file or directory
E/PowerHAL( 511): touch_boost: failed to send: No such file or directory

These are harmless but if you want to eliminate them, just make a backup and delete/rename /system/lib/hw/power.msm8960.so and power.mako.so. The single purpose of touch_boost is to enhance the system response to the user interaction. But using a service in the user space to send a touch boost signal to the kernel via slow sysfs file system is the wrong way of trying to achieve lower latency. In addition, every touch input doesn't need a CPU frequency boost which wastes battery power. The best way of achieving the low-latency system response to user interaction is improving the efficiency of existing CPU governor which raises the CPU frequency and hotplug driver which enables off-line cpu cores when needed. In MiRaGe, CPU freq is only controlled by the CPU governor based solely on the CPU load and the latency is low since efficiency is improved by reducing such unnecessary bloat. Additionally, highly-efficient autosmp hotplug driver works in-sync with the CPU governor to enable off-line cpu cores when the the CPU frequency reaches a high threshold and still more compute power is needed. Therefore, touch boost bloat is removed.

With some of the custom ROMs, root is lost after flashing MiRaGe because of using the init scripts in the ramdisk for starting the su daemon. SuperSU is the recommended solution. I might switch to any-kernel-updater to address this problem but as written in the OP, MiRaGe is primarily for the stock ROM. Also, having the full boot image in the zip file is more reliable than expanding/processing/repacking the boot image.

MiRaGe supports init.d if it is setup. To setup init.d do the followings either within ES File Explorer or terminal .

- install busybox (I use busybox on rails)

- create /system/etc/init.d and chmod to 755 (rwxr-xr-x)

- create your init scripts in the /system/etc/init.d directory. Name them 01yourscriptname (e.g. 01mysettings) and chmod 755.

Make sure they are UNIX format (not in DOS/Windows)

.

example:

#!/system/bin/sh
echo 1 > /sys/devices/virtual/input/lge_touch/dt_wake_enabled

- reboot

Here is how to add multiROM support

How to build:

If you are going to distribute your builds, please don't build your binaries with the same name (i.e. MiRaGe) and distribute in this thread. I would recommend you to start an alternative thread. Otherwise the problem reports will be too confusing for everyone.

First requirement is an ARM toolchain for cross compiling, i.e. using an X86 computer to generate ARM binary. I use Linaro tool chain for cross compiling like many others since Linaro specifically develops tool chains that produce optimized binary for ARM architecture.

Linaro toolchains can be downloaded from Linaro binary page. Christopher83 has built the latest Linaro-14.08 toolchain based on gcc-4.8.4 which is stable/reliable and I recommend starting the development with this toolchain.

The binary Linaro toolchain for Linux package needs to be expanded in a certain directory, probably inside the home directory. The source code for kernel is available in my Github repo, You can either download the kernel source as a compressed package or you can git-clone it with the following command (you will need git installed in your Linux computer)

git clone https://github.com/mrg666/android_kernel_mako.git

The kernel source can again be in a specific home directory.

After the source and toolchain are prepared, copy the configuration file for shooter, arch/arm/configs/mako_config, as .config to the root of the kernel source and use the following command to build the kernel

make ARCH=arm CROSS_COMPILE=~/untarred-toolchain-dir/bin/arm-linux-gnueabihf- zImage -j8

Replace j8 in the above command according to the number of cpus you have on your computer.

Also set CROSS_COMPILE based on the directory you have expanded the binary toolchain package in your home directory.

I always use the latest version of Xubuntu x64 (with custom built kernel) on my Linux workstation that has a AMD FX-8320 (overclocked to 4.2 GHz), 8 GB RAM, 500 GB HD. The compile time is about 2 minutes for me using all 8 cores. I have been using Ubuntu since version 10.04 to build Gingerbread, Jellybean, and Linux kernel and updated the OS to each and every new version, all of them worked just fine. There is no magic version of Ubuntu. The build problems arise from the package requirements not the OS version.

The flash package is easy. Just use any-kernel updater package in the OP as a template and replace zImage in /kernel directory with your build. If you want to create a boot image, see this post

Now that you have source and can build the kernel, you can add all the features you want to your own kernel ;)