Quote:
Originally Posted by [ACL]
I agree 100 percent.. and this is why you cant use rootfs (since real androids dont)..lol .. Our new layout is welcomed by the team so far and they are exited that we are killing rootfs with a passion. So keep it to double check but lets keep our goal in mind to stick as closely to android.
With that said, the one we arent using is actually supposed to be used for boot. I want to shink this down to 5mb which will hold the new kernels and its backup initrd. I already use this so i know it works. This way you can update without flashing from inside android if you want. Its a developers dream actually. So even if the new kernel is bad, you simply erase the file and the old kernel will still take over without losing any data. This also allows us to use the reboot feature which isnt on xdandroid but is on cyanogen.
I don't see any harm in having a /cache as well, but since we cant use the native android tools to flash yet it will be useless. But in the future we might since Alex is working on his LK boot loader. This will eventually replace tinboot and get us closer to pureness .. So feel free to allocate a bit for that as well if you want. Not sure how big but if we find a good use for it might as well right?.
So cook up the final mtd parts so we can commit. I have some real work to do tonight so couldnt do anything here. damn job i tell you.. eating me up alive..
Also, haret guys reporting some pan display timeout during android use. Anyone experience that? i checked my logs and been running for 30 mins with nothing, so im hesitant to change our code with their fix. This error is in the frame buffer and it happens when you get the sleep of death.. I asked arrgg to check since he has a whacky rhod400 . I cant replicate the issue.
Also did you check to see if the ril i posted worked for you? if not then we need to build our ril until i can get stine to do it.
Edit: Bro actually i need your help since your scripting is top notch. I never got around to finish the other variants for the kb auto install. This is how i detect it on the install script. I need to fill in the rest of the parts but i think you already have that done. We need the 500 in there and i guess might as well throw in those poor gsm bastards for the future.
Code:
if [ "`cat /sys/class/htc_hw/machine_variant`" == "RHOD40000" ];then
echo "USING EXPERIMENTAL RHOD400 LAYOUT"
cp -f /system/etc/keymaps/rhod400_microp-keypad.kl /system/etc/keymaps/microp-keypad.kl
cp -f /system/etc/keymaps/rhod400_microp-keypad.kcm.bin /system/etc/keymaps/microp-keypad.kcm.bin
cp -f /system/etc/keymaps/rhod400_navi_pad.kl /system/etc/keymaps/raph_navi_pad.kl
else
echo "Add other variants here."
fi
cp -af /system/etc/keymaps/qwerty.kcm.bin /init.etc/keymaps/qwerty.kl /etc/keymaps/
|
That is great news. I cloned cLK on git to play with a bit, but haven't had a chance to get back to it. Hopefully Alex has seen that over in the HD2 area of XDA.
For the code, this is what you want:
Code:
LAYOUT=`/bin/grep ".*0*" /sys/class/htc_hw/machine_variant`
if [ $LAYOUT = "RHOD30000" ] ; then
echo "USING EXPERIMENTAL TILT2 LAYOUT"
cp -f /init.etc/keymaps/tilt2_microp-keypad.kl /etc/keymaps/microp-keypad.kl
cp -f /init.etc/keymaps/tilt2_microp-keypad.kcm.bin /etc/keymaps/microp-keypad.kcm.bin
cp -f /init.etc/keymaps/tilt2_navi_pad.kl /etc/keymaps/raph_navi_pad.kl
elif [ $LAYOUT = "RHOD21000" ] ; then
echo "USING EXPERIMENTAL RHOD210 LAYOUT"
cp -f /init.etc/keymaps/rhod210_microp-keypad.kl /etc/keymaps/microp-keypad.kl
cp -f /init.etc/keymaps/rhod210_microp-keypad.kcm.bin /etc/keymaps/microp-keypad.kcm.bin
cp -f /init.etc/keymaps/rhod210_navi_pad.kl /etc/keymaps/raph_navi_pad.kl
elif [ $LAYOUT = "RHOD40000" ] ; then
echo "USING EXPERIMENTAL RHOD400 LAYOUT"
cp -f /init.etc/keymaps/rhod400_microp-keypad.kl /etc/keymaps/microp-keypad.kl
cp -f /init.etc/keymaps/rhod400_microp-keypad.kcm.bin /etc/keymaps/microp-keypad.kcm.bin
#cp -f /init.etc/keymaps/rhod400_navi_pad.kl /etc/keymaps/raph_navi_pad.kl #does not exist, just following example
elif [ $LAYOUT = "RHOD50000" ] ; then
echo "USING EXPERIMENTAL RHOD500 LAYOUT"
cp -f /init.etc/keymaps/rhod500_microp-keypad.kl /etc/keymaps/microp-keypad.kl
cp -f /init.etc/keymaps/rhod500_microp-keypad.kcm.bin /etc/keymaps/microp-keypad.kcm.bin
#cp -f /init.etc/keymaps/rhod500_navi_pad.kl /etc/keymaps/raph_navi_pad.kl #does not exist, just following example
else
echo "DEFAULTING TO RHOD500 LAYOUT BECAUSE WE CAN'T DETERMINE YOUR MODEL TYPE AND NO .KB FILE EXISTS IN ANDBOOT FOLDER ON THE SD CARD!"
cp -f /init.etc/keymaps/rhod500_microp-keypad.kl /etc/keymaps/microp-keypad.kl
cp -f /init.etc/keymaps/rhod500_microp-keypad.kcm.bin /etc/keymaps/microp-keypad.kcm.bin
#cp -f /init.etc/keymaps/rhod500_navi_pad.kl /etc/keymaps/raph_navi_pad.kl #does not exist, just following example
fi
Note: We never made some of the commits from Haret, so we don't want the navi_pad stuff or it messes up our buttons.
Also, no need for the following stuff since we moved these files into system:
Code:
cp -af /init.etc/keymaps/qwerty.kcm.bin /init.etc/keymaps/qwerty.kl /etc/keymaps/
mount --bind /etc/keymaps /system/usr/keychars
mount --bind /etc/keymaps /system/usr/keylayout
It seems that the init.android from our rootfs requires ueventd and ueventd.rc to be included. I have it to the point where the boot animation starts, but it just goes on forever and never finishes loading. Not really sure how to diagnose that without having ADB. I guess I could upload the files for someone else to take a look at it, but that seems like a lot of effort :P