Guest emc02 Posted March 20, 2012 Report Share Posted March 20, 2012 Wrong thread - That one is AOSP, not coldfusion. uups, sorry :-D Link to comment Share on other sites More sharing options...
Guest vNa5h Posted March 28, 2012 Report Share Posted March 28, 2012 Nothing much from AOSP... Link to comment Share on other sites More sharing options...
Guest vNa5h Posted March 29, 2012 Report Share Posted March 29, 2012 is this any other place to check the progress of this project other than this http://code.google.com/p/ics4blade/ Link to comment Share on other sites More sharing options...
Guest sifri Posted March 29, 2012 Report Share Posted March 29, 2012 Qualcomm released ICS drivers for Adreno 200 for ARMv6 https://developer.qualcomm.com/forum...4#comment-6869 Link to comment Share on other sites More sharing options...
Guest t0mm13b Posted March 31, 2012 Report Share Posted March 31, 2012 I will endevour to get AOSP ICS4Blade up-to-date using the latest repo from Google shortly :) Link to comment Share on other sites More sharing options...
Guest k.d.11 Posted March 31, 2012 Report Share Posted March 31, 2012 I will endevour to get AOSP ICS4Blade up-to-date using the latest repo from Google shortly :) Any luck with the drivers? Thanks! Link to comment Share on other sites More sharing options...
Guest skywave Posted March 31, 2012 Report Share Posted March 31, 2012 (edited) We need to backport a lot of kernel stuff to get full hw acceleration, even with the new qcom drivers. Got it pretty much "working" regarding memory mngmt but every has a yellow tint as in blue is absent in most screens and the wallpaper is a beatiful colorly noise. Kernel remains a big problem, porting a newer one is very hard as the serial port on the blade is on a non default port and i still havent been able to get a real low level debug necessary to get a plain codeaurora kernel port. Things are made even more complicated because there is no MSM7x27 support in the Linux kernel. This is done by codeaurora. Unfortunately codeaurora readds all their modifications from the previous version in one commit instead of merging their commits with kernel.org commits. Otherwise you could simply jump versions by git merge. This also makes backporting stuff unnecessarily hard as it gives many merge conflicts Edited March 31, 2012 by skywave Link to comment Share on other sites More sharing options...
Guest tilal6991 Posted March 31, 2012 Report Share Posted March 31, 2012 Cool! Look forward to seeing your work. Link to comment Share on other sites More sharing options...
Guest k.d.11 Posted March 31, 2012 Report Share Posted March 31, 2012 By hard you mean impossibly hard or time taking hard? sorry just curious if the blade will ever get full hw accel ..thanks! Link to comment Share on other sites More sharing options...
Guest skywave Posted April 1, 2012 Report Share Posted April 1, 2012 Its not impossible and probably very easy to backport the right KGSL stuff. But if you can't get any debugging working its like finding a needle in a haystack while blind. Link to comment Share on other sites More sharing options...
Guest Hoonboof Posted April 1, 2012 Report Share Posted April 1, 2012 Its not impossible and probably very easy to backport the right KGSL stuff. But if you can't get any debugging working its like finding a needle in a haystack while blind. Backporting is easier said than done! stracing stuff is orders of magnitude easier than going at it blind(ish) 8( Link to comment Share on other sites More sharing options...
Guest skywave Posted April 1, 2012 Report Share Posted April 1, 2012 Backporting is easier said than done! stracing stuff is orders of magnitude easier than going at it blind(ish) 8( Yes, even small things can lead to a motherload of dependencies you need to backport. 2.6.35 is already almost 2 years old, which especially the way Codeaurora manages versions is measurable in lightyears. I hope that with 3.3+ where the Android drivers are in the kernel.org, more codeaurora patches will be send upstream. Link to comment Share on other sites More sharing options...
Guest k.d.11 Posted April 2, 2012 Report Share Posted April 2, 2012 Its not impossible and probably very easy to backport the right KGSL stuff. But if you can't get any debugging working its like finding a needle in a haystack while blind. Thanks for explaining! I hope you guys get aosp ics uptodate with respect to the other ics rooms soon! Link to comment Share on other sites More sharing options...
Guest d_borghi Posted May 5, 2012 Report Share Posted May 5, 2012 Reserved 1st December 2011. What's working:Touchscreen (single - Props to Tilal6991 for his solution)WiFiBlueTooth (Props to Ippe H)Radio (3G data unconfirmed, Props to Ippe H, Hecatae)AutoRotation/Sensors (Props to Ippe H)Audio (WIP - Props to Kallte Kaffe) PLEASE DO NOT ASK FOR DOLBY! Home key working (Props to FelixL)GPS (Props to SkyWave)SDCard (Props to KonstaT) What's not working: Hardware Acceleration (Not yet until confirmed)Armv6-VFP Dalvikvm (Not yet until confirmed)CameraAnything else... There may be other issues that are yet to be discovered... I intend to keep this post updated. Feel free to notify via this thread. Attention for the impatient - PLEASE DO NOT POST "When will it be ready" or "Does so-and-so work?" or rubbish like that as they will be ignored! Edit: 26th December 2011. What's working:Armv6-VFP Dalvikvm - it works but something deep within the bowels of it is broken which produces poor Antutu benchmark ratings on CPU Integer/Floating Point performance.In-call bluetooth for my zte blde CHINAUNICOM doesn't work, camera too. :( bye db Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now