[Atrix 4G Android Development] PolesApart:
It's tricky. What happens is that the way motorola implemented this, there's a userspace program called whisperd that reacts to some kernel events, attempting to figure out what accessories are enabled, and then telling the kernel about it. Only then, the kernel informs android.

The thing is that the whisperd isn't working at all, both because it has permission problems (easy to fix) and it fails to issue the right command to the kernel (not so easy to fix because I don't have the tools, this involves some bad interaction between what kernel headers says and the android view of them (I think they take the ioctl references from other kernel sources, or something like that)).

What I did was to cheat in the kernel for those devices that we're able to detect without the whisperd. Currently that's the multimedia dock and the car dock. The problem is that the car dock detection trick I wrote would confuse the wall charger w/ the car dock. [MENTION=5181088]Zn7mkUKzN1r8aCIV[/MENTION] rewrote this to fix that, and now (I didn't look why) the car dock is only detected when power is off. If the power is on, then the "dock mode" is undone.

In short, whisperd does some things the kernel currently doesn't, and I don't think the cheats could get all cases without actually doing what whisperd is supposed to do.

At this point I do believe this will stay as is (minus the car dock issue which I can take a look when I have the time). Android Lollypop is supposed to be lauched by now, and I think Z will play with it for a while. When we have a release we can coordinate with him and try to get this fixed once and for all. I do believe that we have to use our kernel include headers instead of android's ndk or whatever it uses, then the whisperd whould work (fixing the permissions is just a matter of editing a file in android) and we can drop these hacks.

If that proves difficult for any pratical reason, we can always port whisperd into the kernel. Writing the code is moderately easy, debugging it might be a PITA, though.

---------- Post added at 01:06 PM ---------- Previous post was at 12:59 PM ----------

Nice catch. No, it's regular. I'll upload a hporch32 version. Please everyone, keep trying the hporch32 over the other. I had a screen corruption on resume with this kernel, that's why I turned hporch32 off. But if nobody else gets screen corruption, we can assume there's nothing wrong with hporch32 for all hardware and move on, i.e. assume what I saw was an isolated case.

Otherwise, we'll have to stick with separated kernels, until we can find a better way of not doing the detection (motorola didn't need a separated kernel, so in theory we shouldn't either).

---------- Post added at 01:59 PM ---------- Previous post was at 01:06 PM ----------

As for the crashes, the ideal would be to capture the last_kmsg. I'm using this script in /data/local/userinit.sh :

#!/bin/sh
if [ -e /proc/last_kmsg ]; then
echo "***CUT***" >>/data/local/last_kmsg
cat /proc/last_kmsg >>/data/local/last_kmsg
fi

What it does is, at boot, detect if the previous boot was abnormal and a last_kmsg could be retrieved. If so, it appends it's data to /data/local/last_kmg file, that you can check (later to the fact) to see if there's anything too personal to leak, and if not, post here. Specially if there's some obscure lines at the very end of file (or before each "***CUT***" marker).

As for waze, there are two factors in play: one is that waze has a very fragile filesystem layout. We can actually say it's a waze bug. Even when reboots aren't frequent, waze corrupts it's filesystem, that happened to me from cm9 onwards.

The other factor, which aggravates that, is that I enabled some optimization that tries to defer filesystem writing when screen is on. This should make most workloads smoother. Some (most, if the usage is light) of the writing is only done on screen off. The problem of course is that if the phone crashes with the screen on, more data could be lost. Most apps have decent journalling in their internal data and behave well on crash, the known exceptions are waze and Swiftkey keyboard: this one loses it's dictionary.