I have been working on porting CM9 to the VS910. So far I have gotten it to boot to the lock screen.
What Works
Boot animation
Lock screen
SurfaceFlinger
logcat/adb shell
3d accel is half working. I have gotten SurfaceFlinger to load up and interface the proprietary drivers (from GB) correctly, but HardwareRenderer (java framework) fails because the drivers don't give up a valid config.
What Doesn't Work
Touch screen
HardwareRenderer (fails because HardwareRenderer.chooseEglConfig() returns null value)
Everything else
Currently this ROM is totally unusuable for anything except for development. At this point, I do believe it is possible to get CM9 running, but it will take a good bit of developer effort. It would be helpful for any other developers around here to give some insight on the errors that come up in the adb logs.
How To Build
Follow Google's instructions for setting up a Linux system or VM for Android AOSP building
Follow CM9 build instructions up to brunch command
git clone git://github.com/andyichr/makerom.git to a location, such as ~/android/makerom
Overlay the files in ~/android/makerom/cm9-system/overlay onto the cm9/system directory (this adds vs910 brunch)
Adjust values in makerom.sh to match your own paths (MAKE SURE TO POINT IT AT A VALID KERNEL --I didn't include instructions for building a kernel)
Adjust values in makecm9.sh to match your own paths
Run ~/android/makerom/makecm9.sh to build cm9 (this takes a long time, depending on your system)
If build is successful, run ~/makerom/makerom.sh which will output a ROM which may be flashed to the device for testing
This is very rough work, but it proves that the basic parts of CM9/ICS do function on the Revolution. The cyanogenmod developers have already added some patches to the android source which allow ICS to run using video drivers from Gingerbread. This means it should be possible to get things working.
The current major problem with this ROM is that the HardwareRenderer does not initialize. Immediately after this, the main trebuchet process is killed and the system reboots itself after a while.
I will be happy to do what I can to support the process of porting CM9 to our phones. I read that a couple of other devs may be looking into porting CM7, but I think focusing on 9 might be more worth the effort, since we already have Gingerbread.
I have also attached a logcat to this post which should give developers some idea about what exactly is broken, which will lead to the first steps of debugging and porting.
Any interested developers should fork my repo on github (git://github.com/andyichr/makerom.git) which has the build scripts and patches.
That's about it for now. I very well may have left out some steps along the way. If you try to follow this process and it doesn't work out, let me know and I'll help you out.
ROM Download (very broken --only use for testing and development)
http://www.multiupload.com/GI0MLQYTE0 - Flash this if you want to see ICS boot to the lock screen or help test/debug. It's not useful for much else at this point.
We're getting there! I've already patched the android egl framework code slightly and built a kernel. CM team already patched frameworks/base for 2.3 video drivers. We'll patch what we have to to get this thing running! I am pretty busy but I will follow this thread and I hope for this to be a collaborative, transparent porting process! Good luck!
Nice, get with Mtmichaelson and Cubed, they are working on Cm9 also!
Sent from my VS910 4G using Tapatalk
Great! I saw in the CM7 thread that thecubed put up a git repo. I'm not sure exactly what his development plan is, but I'd be happy to fork his repo and trade patches, logs, etc. The more devs we have on this, the better... it's not a trivial task and I'm sure my wife hates me by now for spending so many hrs on it so far.
If I read correctly, thecubed just got a master repository set up for the revolution, so maybe the files that are needed could be lurking in there? I'll see if I can find the link and post it here.
Here's the link: https://github.com/thecubed
BLITZ ledded adshot nitro supercharged Gingerlution
I know in irc tonight cubed was talking about it. Guess they have to work on a few things but it's coming along. Wish I knew more so I could help out in this to. Guess I could be the Guinea pig.
Sent from my VS910 4G using Tapatalk
aichrist said:
Great! I saw in the CM7 thread that thecubed put up a git repo. I'm not sure exactly what his development plan is, but I'd be happy to fork his repo and trade patches, logs, etc. The more devs we have on this, the better... it's not a trivial task and I'm sure my wife hates me by now for spending so many hrs on it so far.
Click to expand...
Click to collapse
Awesome job so far! For a lot of things to work correctly, it's my understanding that you'll need a new kernel. For at least the touchscreen issues, you need the "idc" file in the "/system/usr/idc" directory (not sure if you have that or not, I didn't get a chance to check yet)
Either way, if you'd like to get in contact with me, hop on IRC and I'd be happy to answer any questions you may have.
Excellent work!
indyred99 said:
I know in irc tonight cubed was talking about it. Guess they have to work on a few things but it's coming along. Wish I knew more so I could help out in this to. Guess I could be the Guinea pig.
Sent from my VS910 4G using Tapatalk
Click to expand...
Click to collapse
Yeah I see thecube's repo at https://github.com/thecubed/android_device_lge_revolution. His CM files are a lot cleaner than mine... I just copied the crespo config and haven't had time to clean it up yet. I'll do some diffs of his vs mine and see about getting things merged. My github repo has some additional files so what I could do is replace my vs910 device folder with a fork of thecube's repo.
I'm not sure whether his files are for CM7 or CM9 (or if it doesn't matter). I'm new to CM porting, but I'm not new to linux or android app development.
thecubed said:
Awesome job so far! For a lot of things to work correctly, it's my understanding that you'll need a new kernel. For at least the touchscreen issues, you need the "idc" file in the "/system/usr/idc" directory (not sure if you have that or not, I didn't get a chance to check yet)
Either way, if you'd like to get in contact with me, hop on IRC and I'd be happy to answer any questions you may have.
Excellent work!
Click to expand...
Click to collapse
Thanks for the tip. I'll check that out. So far I've mainly been banging my head on getting the adreno205 drivers working, but it sure would be nice to have touch working. That'd be the next priority.
I'm tempted to switch of 3d acceleration but I am focusing on one thing at a time.
I'll hop on IRC. Which channel are you on specifically?
As always guys, I'm happy to assist in testing. Nor very knowledgeable on coding or porting, but I can definitely put my phone at risk
BLITZ ledded adshot nitro supercharged Gingerlution
wish I knew more about this stuff so I could help
keep up the great work!
crossing fingers, hoping I'll get the chance to start making themes for CM9!
aichrist said:
Thanks for the tip. I'll check that out. So far I've mainly been banging my head on getting the adreno205 drivers working, but it sure would be nice to have touch working. That'd be the next priority.
I'm tempted to switch of 3d acceleration but I am focusing on one thing at a time.
I'll hop on IRC. Which channel are you on specifically?
Click to expand...
Click to collapse
Head over to #lgrevolution and I'll be there as IOMonster.
Yep, for ICS we need a lot of work in the KGSL department in kernel for getting proper Adreno support working... Tiamat is working on adding the new KGSL/USB/Genlock support to his MSM7X30 repo here ( http://git.tiamat-dev.com/7x30/htc-kernel-msm7x30/ ) and after that we need to merge our kernel sources with his (boardfiles, includes, configs, etc)
Booting to lockscreen is great, but there's a LOT of work to be done before we can have a "working" ICS by any stretch of the imagination... ICS is a whole new beast, unfortunately...
Cubed beat me to it.
Sent from my VS910 4G using xda premium
thecubed said:
Head over to #lgrevolution and I'll be there as IOMonster.
Yep, for ICS we need a lot of work in the KGSL department in kernel for getting proper Adreno support working... Tiamat is working on adding the new KGSL/USB/Genlock support to his MSM7X30 repo here ( http://git.tiamat-dev.com/7x30/htc-kernel-msm7x30/ ) and after that we need to merge our kernel sources with his (boardfiles, includes, configs, etc)
Booting to lockscreen is great, but there's a LOT of work to be done before we can have a "working" ICS by any stretch of the imagination... ICS is a whole new beast, unfortunately...
Click to expand...
Click to collapse
Great --I'll be on the channel as achristianson or achristi.
Thanks so much for all that info.
I'm sure it is a long road to a fully working ICS. I see it as a challenge and will just keep fixing the next broken thing...
I'd be happy to test this. I got a spare revo cuz I had a warranty and this dent on the outer corner was driving me nuts.
Gingerfused Gingervolt 1.3 + Blitz
It's really awesome to see everyone working on this. I really wish I knew more about this stuff to be able to help. All this is really making me wanna read up on this stuff and learn how to do some of it. Until that happens, I'll be more than happy to help out with any testing or in any other way within my capabilities. I got a Revo just sitting there deactived waiting for that ICS goodness.
Thanks a lot for everyone working on this. Those of us that aren't as gifted really aprreciate the work you guys are putting in.
Grizzy3 said:
It's really awesome to see everyone working on this. I really wish I knew more about this stuff to be able to help. All this is really making me wanna read up on this stuff and learn how to do some of it. Until that happens, I'll be more than happy to help out with any testing or in any other way within my capabilities. I got a Revo just sitting there deactived waiting for that ICS goodness.
Thanks a lot for everyone working on this. Those of us that aren't as gifted really aprreciate the work you guys are putting in.
Click to expand...
Click to collapse
If you've noticed my post in the CM7 Thread, which somehow 'feels' like it's sparked something off here (maybe just timing, lol), I am beginning to work on this stuff.
Anyone can do it, but the problem is motivation and the willingness to learn something new. You will never learn this stuff unless you're willing to fail and fail again. You learn by mistakes and mistakes sometimes turn into innovation for new things and ideas.
There is a lot of Dev's all of a sudden and I do agree, it's great to see. I was almost about to start looking at the Nexus. When I realized I would lose out on the $130 of extra accessories for my Revo (Car Dock, home dock, extra battery, car charge, etc.), And the fact the the Nexus had no External SD Card, I was like... Nah.. Time to step up and see what I can do to make the Revo a well-supported, up to date, kick-ass device. If LG and Verizon wanna sit on their asses, let'em. We make the phone better anyhow, right? MT, Cubed, and anyone else who has already contributed so much, has made this phone 10X's what it ever was out of the box. And, unlike LG and Verizon, Dev's like MT (and others) don't give us the run around on the next release, but a timeline.
-Cybie
Cybie257 said:
If you've noticed my post in the CM7 Thread, which somehow 'feels' like it's sparked something off here (maybe just timing, lol), I am beginning to work on this stuff.
Anyone can do it, but the problem is motivation and the willingness to learn something new. You will never learn this stuff unless you're willing to fail and fail again. You learn by mistakes and mistakes sometimes turn into innovation for new things and ideas.
There is a lot of Dev's all of a sudden and I do agree, it's great to see. I was almost about to start looking at the Nexus. When I realized I would lose out on the $130 of extra accessories for my Revo (Car Dock, home dock, extra battery, car charge, etc.), And the fact the the Nexus had no External SD Card, I was like... Nah.. Time to step up and see what I can do to make the Revo a well-supported, up to date, kick-ass device. If LG and Verizon wanna sit on their asses, let'em. We make the phone better anyhow, right? MT, Cubed, and anyone else who has already contributed so much, has made this phone 10X's what it ever was out of the box. And, unlike LG and Verizon, Dev's like MT (and others) don't give us the run around on the next release, but a timeline.
-Cybie
Click to expand...
Click to collapse
Exactly how i feel. Forget LG and Verizon. You guys are the ones taking these average phones into something great. I definitely gave up on getting any real support from either of them.
I really want to start getting into this. I have a little bit of time on my hands and will definitely be reading up on all this. I think you sparked something with your post lol. I know other people like MT and theCubed were already working on some things but I think you definitely added a little spark lol. Very happy to see other people jumping on board to help out. Hopefully I can too
Grizzy3 said:
Exactly how i feel. Forget LG and Verizon. You guys are the ones taking these average phones into something great. I definitely gave up on getting any real support from either of them.
I really want to start getting into this. I have a little bit of time on my hands and will definitely be reading up on all this. I think you sparked something with your post lol. I know other people like MT and theCubed were already working on some things but I think you definitely added a little spark lol. Very happy to see other people jumping on board to help out. Hopefully I can too
Click to expand...
Click to collapse
Yup! The motivation for me has been that support by LG and VZ is diminishing. This is the beauty of open source, though. Now the community can support it.
I believe the Revolution really is a good phone. It's got a good GPU and CPU. It's not dual-core, no, but with a good ROM on there, it can be much more efficient than a dual-core phone that is loaded with crapware.
Cybie did inspire me to put my work up sooner so that we can all focus on it and not duplicate our efforts as much.
thecubed said:
Head over to #lgrevolution and I'll be there as IOMonster.
Yep, for ICS we need a lot of work in the KGSL department in kernel for getting proper Adreno support working... Tiamat is working on adding the new KGSL/USB/Genlock support to his MSM7X30 repo here ( http://git.tiamat-dev.com/7x30/htc-kernel-msm7x30/ ) and after that we need to merge our kernel sources with his (boardfiles, includes, configs, etc)
Booting to lockscreen is great, but there's a LOT of work to be done before we can have a "working" ICS by any stretch of the imagination... ICS is a whole new beast, unfortunately...
Click to expand...
Click to collapse
OK so I was doing more debugging last night in the EGL/SurfaceFlinger/HardwareRenderer code. I also looked at some of Tiamat's work on the MSM7X30 kernel.
I can see now what you mean with regard to merging parts of that kernel into our own. I am assuming that kernel is being crafted to work with ICS-friendly EGL blobs for the adreno205. Is that correct? If so, then that kernel would have code that would be required to talk to the binary blob EGL drivers for Adreno205 that we would pull from some device that has the same chip and has official proprietary drivers for ICS available. I believe the HTC Droid Incredible 2 is one such device. Is this roughly what you were thinking?
I initially had thought of going down a different path: Instead of using newer ICS proprietary drivers and updating our kernel to support it, I was planning on keeping the kernel we have and the binary drivers we have, which are already made to work with each other. The work then required to get ICS working would be to change parts of the ICS userspace code such that they'd work with our older drivers. I don't have the links on hand, but I believe this is possible because I read about others taking this strategy on other devices that do not have ICS support officially but do have proper GB support. It also makes sense to me logically that the userspace code could be changed to our heart's content to work with older drivers, since we have full access to that source code. One option that I read about that we could potentially do is write a wrapper for the *adreno200*so librares that would implement the newer API that ICS is expecting and would translate the calls into the older API that is supported in our GB proprietary drivers.
It looks to me like we have two possible ways forward with regard to getting hardware acceleration working: upgrading the kernel and drivers to have "proper" ICS support, or patching ICS userspace code to work with GB drivers and kernel. I believe that patching the ICS userspace code would get us up and running faster while upgrading the kernel and adding newer drivers would be the better long-term solution.
Here are a couple of patches that people have already implemented to support older EGL blobs/kernels:
https://github.com/VorkTeam/android_frameworks_base/commit/429e922fb6f2660fc40472e939175688af52b1d2
https://gist.github.com/CyanogenMod...mmit/5d689bd02531f8ff256b3b1eddcaa8040c9f3559
https://gist.github.com/CyanogenMod...mmit/f8e2430be2d6b3e88afd7190f6712f3bc1df0cbf
Let me know what you think.
Also, what do you think about using the BOARD_USES_QCOM_HARDWARE := true directive to our CM board configuration? I noticed references to the QCOM_HARDWARE flags all over the video code. It seems we would want this since we are using a QCOM video chip. The only problem is the build failed for me when I added this flag. There's an issue about it on github: https://github.com/CyanogenMod/android_hardware_qcom_display/issues/3#issuecomment-3457179.
aichrist said:
OK so I was doing more debugging last night in the EGL/SurfaceFlinger/HardwareRenderer code. I also looked at some of Tiamat's work on the MSM7X30 kernel.
I can see now what you mean with regard to merging parts of that kernel into our own. I am assuming that kernel is being crafted to work with ICS-friendly EGL blobs for the adreno205. Is that correct? If so, then that kernel would have code that would be required to talk to the binary blob EGL drivers for Adreno205 that we would pull from some device that has the same chip and has official proprietary drivers for ICS available. I believe the HTC Droid Incredible 2 is one such device. Is this roughly what you were thinking?
I initially had thought of going down a different path: Instead of using newer ICS proprietary drivers and updating our kernel to support it, I was planning on keeping the kernel we have and the binary drivers we have, which are already made to work with each other. The work then required to get ICS working would be to change parts of the ICS userspace code such that they'd work with our older drivers. I don't have the links on hand, but I believe this is possible because I read about others taking this strategy on other devices that do not have ICS support officially but do have proper GB support. It also makes sense to me logically that the userspace code could be changed to our heart's content to work with older drivers, since we have full access to that source code. One option that I read about that we could potentially do is write a wrapper for the *adreno200*so librares that would implement the newer API that ICS is expecting and would translate the calls into the older API that is supported in our GB proprietary drivers.
It looks to me like we have two possible ways forward with regard to getting hardware acceleration working: upgrading the kernel and drivers to have "proper" ICS support, or patching ICS userspace code to work with GB drivers and kernel. I believe that patching the ICS userspace code would get us up and running faster while upgrading the kernel and adding newer drivers would be the better long-term solution.
Here are a couple of patches that people have already implemented to support older EGL blobs/kernels:
https://github.com/VorkTeam/android_frameworks_base/commit/429e922fb6f2660fc40472e939175688af52b1d2
https://gist.github.com/CyanogenMod...mmit/5d689bd02531f8ff256b3b1eddcaa8040c9f3559
https://gist.github.com/CyanogenMod...mmit/f8e2430be2d6b3e88afd7190f6712f3bc1df0cbf
Let me know what you think.
Also, what do you think about using the BOARD_USES_QCOM_HARDWARE := true directive to our CM board configuration? I noticed references to the QCOM_HARDWARE flags all over the video code. It seems we would want this since we are using a QCOM video chip. The only problem is the build failed for me when I added this flag. There's an issue about it on github: https://github.com/CyanogenMod/android_hardware_qcom_display/issues/3#issuecomment-3457179.
Click to expand...
Click to collapse
You guys are great! I hope this is doable, keep up the hard work..
Sent from my Nexus S 4G using XDA App
Related
This thread is in regard to the unofficial development of the Cyangonmod 7.1 for the Dell Streak 7. Absoluetelly nothing works. So a lot of work needs to be done.
First git the entire Cyangonmod 7.1 tree from them, and then drop these files into the device/dell/streak7 folder
http://www.mediafire.com/?q1w57v797u9p953
This rips the files from a stock Android 2.2 image, so you need to make sure that you are at a stock 2.2 image. My next goal is to upgrade to a stock HC and try making the scripts for that and see if it gets me closer.
As of right now, it boots "Dell" logo, then goes to the black screen with "ANDROID" on it, and that is as far as I can get it.
Look at the files, and let me know what changes I should make and in what script.
Driver wise, I believe you might be better off trying to backport the stock HC drivers.
GB <-> HC/ICS are more similar then eclair/froyo <-> GB in respect to drivers.
That's the reason it took half a year to hack together GB for the s5 and why it only tooks weeks to hack froyo from eclair
Rumor has it that dell attempted to port GB to the s7 before giving up, they lost a couple months at Q12011 doing that and likely scrapped everything, then they restarted on porting 3.1 then moved to 3.2 and that's why the summer was pretty quiet and why the S5 prob got no updates all summer
I dont have any substantial evidence to back any of it up, but the timelines all line up far too nicely, dell prob has only a single team for the s5/7/venue, the s10 is done by a different company.
Yeah, I am thinking I am going to try that direction next. Got a list of all the libs, now just need to re-write the scripts.
CM 7.1, Is that gonna be Honeycomb based?
Mysticales said:
CM 7.1, Is that gonna be Honeycomb based?
Click to expand...
Click to collapse
CM7 is Gingerbread...
Nice, gonna check this out once it arrives
You should have killed me, when you had the chance
Mysticales said:
CM 7.1, Is that gonna be Honeycomb based?
Click to expand...
Click to collapse
Cm never did honeycomb because google never released source
I've pulled a list of all the files I need to work with, now will be the time consuming part of checking the scripts to see if they are already listed and then adding the ones that are not listed.
Not to sound negative, but with Dell having released the official HC build and so, would people really use Gingerbread on their tablet?
Mysticales said:
Not to sound negative, but with Dell having released the official HC build and so, would people really use Gingerbread on their tablet?
Click to expand...
Click to collapse
I'm doing this for the same reason any hacker does anything.
For the sheer f*** of doing it.
Currently I am working on building a tegra2 2.6.35 gingerbread kernel.
Hypothetically, if he can get GB to actually work (and by work i mean functional with all the hardware functioning properly) he'll be a dozen steps closer to being able to port over to ICS.
I cant say that it would ultimately lead to ICS, but the documentation generated would help a lot (assuming it's all documented lol)
Documentation......I knew I was forgetting something.
Well, the easy steps right now will be as soon as I get it to boot using CM7.1, i will figure out how to git it up to Cyangonmod and have them review it. Currently I got the information I need to port to CM7.1, its just a matter of plugging that information in. The problem I am wondering is that the current kernel in their directory, I have no idea who built it or what it contains.
Building a working kernel is very tough since I have never done it before. Nvidia does have a Tegra 2 Gingerbread image built and a Tegra 2 Gingerbread kernel build available, its just a matter of me figuring out how to get them to work because I have never done this before.
So this usually consists of me doing the following
1. Run 'make -j4'
2. Get error
3. Research error
4. Attempt some fixes
5. Repeat step 1-4
The s7 is really similar the nvidia's vendeta reference board, and I think that's what dell tried to base their GB attempt off of.
(Also what cpu are you using? -j4 is small unless you're compiling on a laptop or something)
TheManii said:
The s7 is really similar the nvidia's vendeta reference board, and I think that's what dell tried to base their GB attempt off of.
(Also what cpu are you using? -j4 is small unless you're compiling on a laptop or something)
Click to expand...
Click to collapse
Actually it is the ventana (tegra 2 250) board as far as I can tell.
I've got a couple files that say 'init.ventana.rc' on them, plus 'init.streak7.rc'. These were pulled from the ~/ directory
I am in contact with Nvidia in regard to some questions I have but haven't heard from them in a week, they are probably slammed with questions all the time.
Just wanted to say, that nice to see someone interested and capable in doing something for streak7. keep up mate
Sent from my Dell Streak 7 using Tapatalk
giveen said:
I'm doing this for the same reason any hacker does anything.
For the sheer f*** of doing it.
Currently I am working on building a tegra2 2.6.35 gingerbread kernel.
Click to expand...
Click to collapse
Oh dont get me wrong, Its cool that you do that, its the same reason I mess around. I guess its just with Steve working on Honeystreak R8+ and ICS. Just was a wonder how many would use GB.
Too bad one can dual boot. Like have HC on Nand, and boot into a diff Android build on SD. Why would this be cool? Cause honestly.. sometimes HC can suck, least when it comes to mass storage mode. I could see myself using a dual boot at times to boot in GB with my streak 7. =)
the dell streak 7 has a Nvidia Harmony broad also could you not use cm7 Advent Vega as a base
Yes, I have looked into it, and in fact I've stolen lots of information from that build and put into into the build system I am working on.
So before I go on a holiday break, a bit of an update.
Bad News:
I started all over and started working my scripts. Currently its having a problem with my 'recovery.fstab'. Its saying its not there, but I FREAKIN KNOW ITS THERE!!!!!! and its written correctly in my scripts.
Good News:
Two successfull zImages built, one based off of Nvidia's 2.3 stuff combined with DJ_Steve's configuration, probably won't boot because its missing some drivers.
And the other is a DJ_Steve's HC kernel, but I asked him to check over some errors I got, even though it successfully built.
The reason why I built new zImages is because I couldnt' verify who created the kernel file in the github. The label on the folder was 'koush' but I asked him and he said he did not build it, so I have no idea who started the project, hence why I decided to build a new one.
So AFTER I figure out the recovery.fstab error, I will try out both of my new kernels and see which one does the job.
After I take a break.
I got several errors out of the way but....
The CM7 build is on hold, indefinitely. I am currently helping out with the ICS build and it takes a lot of my time and also taking care of my pregnant wife and two children. With the release of ICS, I might not even bother with it after this. And if I do, it will be a casual effort.
I see working on the ICS build as the assistant to a very talented ROM developer a a huge learning process and it is actually helping me become much better at making ROM's.
So CM7 was a stellar success for our tiny lil device called Tattoo.
Now that CM7 is over, we'll are eagerly waiting for CM9. I posted this thread to know if Tattoo is going to be supported in the CM9 builds. If anyone of you has an idea of what is going on, you can reply here. Also you can use this thread for dev purposes.
Others here, you can list out what features you want to see on out Tattoos running CM9. This can come of great help to the devs until the actual thread comes up.
So when many devices have got early CM9 builds, why not us? arco68 and KalimochoAz, you there?
The CyanogenMod team already announced that one phone which will not get the upgrade is the Motorola Droid because of it's outdated hardware. You know, Droid is really similar to Tattoo specwise. Same CPU specs, same RAM amount, same internal memory.....
You draw the conclusions.
pretty bleak future for us indeed. but the hero and the G1 are running early builds of it already. so if G1 can do, why not Tattoo?
sunitknandi said:
pretty bleak future for us indeed. but the hero and the G1 are running early builds of it already. so if G1 can do, why not Tattoo?
Click to expand...
Click to collapse
Any hope for us. Be patient. They only write about Droid1: http://www.cyanogenmod.com/blog/cm9-progress-update
BilboPC said:
Any hope for us. Be patient. They only write about Droid1: http://www.cyanogenmod.com/blog/cm9-progress-update
Click to expand...
Click to collapse
This blog post pretty much confirms that we won't be getting CM9.
Our goal is to provide continued support to all CM7 devices back to the QSD8250 series of devices such as the Nexus One.
Click to expand...
Click to collapse
Our device is MUCH less-powerful than the QSD8250, which is a 1.0-1.2GHz CPU and Adreno 200 GPU System-on-a-Chip.
if that is true, wildfire wont get it too.
My guess it it will run. But should be optimized heavily for a smooth experience.
Sent from my HTC Tattoo using XDA App
I'm afraid the low resolution will be the show stopper there.
Maybe possible but it will be light version of ICS a few of the ingredients may be removed.
The screen is 2.8" n this is maybe the drawback...
I have installed ICS on G1. Its horrible ROM, Very Laggy and still needs lot of development for smoother experience. They haven't fixed the rotation problems yet. It looks to me Tatto0 will have a hard time with CM 9 because of its lower quality hardwares.
Tattoo is a 2 years old phone
Once we made it 2.1/2.2
It great already
And now we even have 2.3
What are we still asking for
As google told before
4.0is for high end
So let's enjoy the extra bonus that we get
Sent from my HTC Sensation XE with Beats Audio Z715e using XDA App
There was a Christmas gift to buzz community from Arco
http://forum.xda-developers.com/showpost.php?p=20639586&postcount=61
which i think is a good news for Tattoo as well in terms of CM9
i still have hope!
it might not be a perfect version of android 4, but at least we can try and have fun a little bit while we wait for next year's christmas for a new phone!!
Look at this
http://www.youtube.com/watch?v=Ym4A82ft5pw
It's ICS running on htc g1, the first android phone! I hope we can run it also on our tattoo
mattia29 said:
Look at this
http://www.youtube.com/watch?v=Ym4A82ft5pw
It's ICS running on htc g1, the first android phone! I hope we can run it also on our tattoo
Click to expand...
Click to collapse
Yes, it's running, but as you can see it's too slow, really.
Yes but tattoo has a little better specs than G1
Hey all,
If no-one is looking at porting CM9 to Tattoo, I could have an indicative look at doing it; no promises though; as I am doing it for HD2 at the moment, where I am spending all my time
I may have a go in a few days.
Although I may need some assistance with drivers and kernel later on
arif-ali said:
Hey all,
If no-one is looking at porting CM9 to Tattoo, I could have an indicative look at doing it; no promises though; as I am doing it for HD2 at the moment, where I am spending all my time
I may have a go in a few days.
Although I may need some assistance with drivers and kernel later on
Click to expand...
Click to collapse
That's awesome, man. I would done it if I had knowlege
arif-ali said:
Hey all,
If no-one is looking at porting CM9 to Tattoo, I could have an indicative look at doing it; no promises though; as I am doing it for HD2 at the moment, where I am spending all my time
I may have a go in a few days.
Although I may need some assistance with drivers and kernel later on
Click to expand...
Click to collapse
Please do it if u have time.
Update on compilation
Hi all,
Everything I do is all open, so you will see what I have done; this also gives others the chance to contribute
If someone wants to see my progress, then you can go to the following git repo
https://github.com/arif-ali/android_device_htc_click
and when I have a build it will be located here
http://cyanogenmod.arif-ali.co.uk/rom/test
So far quite a bit compiles, working on the wpa_supplicant part now. Looks like it may be a hack or need to look somewhere else.
I've had the Tattoo for 2 years now, but don't really know the HW much, so much research will be required. I've just installed nfinityGB, as and when arco built it.
If someone can give any input, it may speed up my work; and it will be appreciated.
Edit 1:
* Got passed the wifi, just got the drivers from gingerbread (for my notes)
Code:
cd system/wlan
git clone git://github.com/CyanogenMod/android_system_wlan_ti.git -b gingerbread
mv android_system_wlan_ti ti
sed -i s/LOCAL_MODULE_TAGS.*/LOCAL_MODULE_TAGS\ :=\ optional/g system/wlan/ti/sta_dk_4_0_4_32/config/Android.mk
* Need http://forum.xda-developers.com/showpost.php?p=20737947&postcount=27 for compilation as well
Code:
unzip ../webrtc.zip -d external/webrtc/
Edit 2:
Good News; first compile done.
Bad News; it's 4am in the morning, and I can't be bothered to test
I have no idea if it is going to work or not, and if someone is really adventurous, then feel free to try flashing the file from the following URL in about 20 mins i.e. better to try 04:30 GMT to be on the safe side
http://cyanogenmod.arif-ali.co.uk/rom/test/update-cm9-click-20120101.zip
system is going to be 162M, and gapps can be downloaded from http://cyanogenmod.arif-ali.co.uk/misc/gapps-ics-20111128.zip
Personally, I won't be able to test until tomorrow now
Edit 3:
NVM, this won't work, our system is only 150M; I will give it another go later
All those able to make use of this information may want to look here.
http://forum.xda-developers.com/showthread.php?t=1609654
Hash said on twitter it was to much work to get this to work with the d3 and ics,unless I missunderstood his tweet the other day..
[email protected]_Carbone
kexec stuff for D3 isnt useful w/o a 3.x kernel. Which would be a ton of work.
@Motorola needs to say what's happening w/D3.
6:39pm - 28 Apr 12 via Plume for Android
Click to expand...
Click to collapse
I saw. Getting kexec itself up and running is one (positive) thing. Then wed need the 3.0 kernel. Kernel source of RAZRs ICS may not be far off and may help.
There are also people (search Kabaldan) who can pull of porting of kernel bits - as with the original Milestone and a similar exploit.
That guy is a genius.
Kabaldan its a great dev with huge skills and enthusiasm, i have milestone #1 so he was my little god.
maybe We should think or not to buy him one piece droid3: D all of us invest a some $$ but benefits will be enormous i thinkg
Get that person who startd the thread in the general section to send one theirs to him lol
Sent from my XT862 using Tapatalk
I think could try hash kindle kernel or even just use the .config from the 2.3.6 posted by moto and fill in the new options. Pretty sure the kernel itself will be easy once kexec is working
Give it a go Willis! we wait with baited breath. If you take on the project id say make a thread for progress updates and donations? Im sure thered be forthcoming donaters.
Ye it wouldn't be fair if D3 was left out
I think it is possible to just cut and paste until we get something solid for us right now.
Sent from my XT862 using XDA
^ joke?
Sent from my XT862 using Tapatalk
MrObvious said:
I think it is possible to just cut and paste until we get something solid for us right now.
Sent from my XT862 using XDA
Click to expand...
Click to collapse
Hmm...no.
Sent from my Galaxy Nexus using xda premium
Lol I'm messing duh.
Sent from my XT862 using XDA
Willis111 said:
I think could try hash kindle kernel or even just use the .config from the 2.3.6 posted by moto and fill in the new options. Pretty sure the kernel itself will be easy once kexec is working
Click to expand...
Click to collapse
I really wish it was that easy. :/ Unfortunately, in many cases kernel changes == userspace binary changes in the OS. And for those, I have no source. So if that item has been customized by Moto.. we're back to some of the hackery that we have now.
Something to keep in mind when checking out how the Kindle works: I was able to drop all of the Amazon custom binaries in favor of generic Texas Instruments alternatives. The Amazon customized android binaries had viable "from source" alternatives in almost every case. There is no way this would be possible for a Moto device. Too much customized hardware/software in the way.
And the Kindle is almost a play toy compared to a phone device. I didn't need to worry about:
Light sensors
Bluetooth
3g Modem
Keyboard
Camera
Etc
And while the base CPU is identical, everything changes from there:
Different charging driver
Battery gauge
LCD driver
Touchscreen driver
Audio driver
Wifi chip is even different and that's supposed to be part of the "system on a chip"
That being said, I know the D3 is probably in the worst looking shape regarding an update from Moto. And, I'm sort of mulling over how to do it right.
While I could probably do a few tweaks to a kexec kernel for:
- graphics drivers which fully support ICS (see: Chrome, RenderScript, etc)
- *maybe* get the backport working for open source hw codecs to support flash, netflix, etc. (I have a good bit of this done as kernel modules from back in January.. just didn't know why they were failing at the time)
But, I'm not sure it's worth the additional effort if we don't get things like camera / video recording working (will probably need custom Moto source for codecs -- open source won't do it). And updating the hw codec engine above would most likely break the current camera hack entirely.
I guess, I would need to see if Moto has any sort of upgrade path for the Droid 3. If they do, then I'd say hang tight and I'll get it integrated once they release something.
Otherwise, we as a community need to decide if a phone which is more ICS friendly but doesn't have a camera is worth it.
Maybe the answer is: finish the CM7 port into something which is more functional and bugfree.
Sent from my XT894 using Tapatalk 2
Hashcode said:
I really wish it was that easy. :/ Unfortunately, in many cases kernel changes == userspace binary changes in the OS. And for those, I have no source. So if that item has been customized by Moto.. we're back to some of the hackery that we have now.
Something to keep in mind when checking out how the Kindle works: I was able to drop all of the Amazon custom binaries in favor of generic Texas Instruments alternatives. The Amazon customized android binaries had viable "from source" alternatives in almost every case. There is no way this would be possible for a Moto device. Too much customized hardware/software in the way.
And the Kindle is almost a play toy compared to a phone device. I didn't need to worry about:
Light sensors
Bluetooth
3g Modem
Keyboard
Camera
Etc
And while the base CPU is identical, everything changes from there:
Different charging driver
Battery gauge
LCD driver
Touchscreen driver
Audio driver
Wifi chip is even different and that's supposed to be part of the "system on a chip"
That being said, I know the D3 is probably in the worst looking shape regarding an update from Moto. And, I'm sort of mulling over how to do it right.
While I could probably do a few tweaks to a kexec kernel for:
- graphics drivers which fully support ICS (see: Chrome, RenderScript, etc)
- *maybe* get the backport working for open source hw codecs to support flash, netflix, etc. (I have a good bit of this done as kernel modules from back in January.. just didn't know why they were failing at the time)
But, I'm not sure it's worth the additional effort if we don't get things like camera / video recording working (will probably need custom Moto source for codecs -- open source won't do it). And updating the hw codec engine above would most likely break the current camera hack entirely.
I guess, I would need to see if Moto has any sort of upgrade path for the Droid 3. If they do, then I'd say hang tight and I'll get it integrated once they release something.
Otherwise, we as a community need to decide if a phone which is more ICS friendly but doesn't have a camera is worth it.
Maybe the answer is: finish the CM7 port into something which is more functional and bugfree.
Sent from my XT894 using Tapatalk 2
Click to expand...
Click to collapse
I personally would love to see cm7 finished. For myself without working video I can't use ics as a daily driver, I need to use skype on my device often. And although its been awhile since I've used ics the battery life was pretty poor compared to gb
Sent from my XT860 using xda premium
If CM9 can be made to work with everything (flash, HW codecs) bar Video that would do me.
Otherwise CM7 completion gets my vote.
Also, how about when Bionic ICS hits? And are RAZR camera/hw codecs of no use?
CM7!
Sent from my DROID3 using XDA
slvrarrow said:
Also, how about when Bionic ICS hits? And are RAZR camera/hw codecs of no use?
Click to expand...
Click to collapse
Turns out the hwcodecs and kernel will be useless for Droid 3. This was something that I learned recently while building the new kernel to the Kindle Fire.
All of the settings in the new 3.0 kernels from TI are hard coded to 1GB RAM. Including the hw codec binary. For the Kindle I had to do quite a bit of rework and dynamic tiler modifications to get ICS running on it correctly.
Can't you use a 2.x Kernel?
slvrarrow said:
Can't you use a 2.x Kernel?
Click to expand...
Click to collapse
I don't think so, I believe ICS depends upon a 3.0 kernel, which is why he's been having such a hard time getting everything to work. He has to rewrite ICS code to work with what we have in our kernel that is meant for Gingerbread.
Update (10/09/2012):
IDLE2 v0.391 - details here.
Known issues:
Bluetooth sometimes doesn't work correctly in rare cases on some devices. I've done all I can with this. Whenever I test it, it works. So this one is going to be for the community to solve, should anyone wish to fix it.
Excessive battery drain during suspend. Unsure why this occurs, I'm investigating. It actually uses less battery if you kill suspend by holding a wakelock. This suggests to me that the device is 'pretending' to go into suspend, it *is* freezing tasks and calling wfi, but I suspect the SoC isn't being powered off, which may be a syscon issue. Time to do more TRM reading.
Update (09/09/2012):
Current version v0.390, which I'm also going to declare stable. It *may* still have minor bugs, but the blockers are definitely fixed, such as the kernel panics and lockups. The code churn is also over, as the implementation is looking good and cheap.
Development is now in this branch.
Changes here, here and here.
I also deleted a load of old crap from below.
Update (30/08/2012):
Still too busy / lazy to update the first post. Actually getting the damn thing working takes priority.
Current development is all taking place in this branch.
Current version (v0.370) highlights:
It actually saves power now after I fixed a few bugs causing stupidly low residencies.
Enabled continually. TOP block will be left on unless the screen is off, or the USB is plugged in.
CPU frequency set to 800MHz at all times whilst screen off
Tons of code re-written / refactored / deleted / reinvented.
Plenty of code comments added.
Statistics exported to /sys/kernel/debug/idle2/statistics (note the changed path) - Enable in menuconfig (CONFIG_S5P_IDLE2_STATS) (Would be better if this were disabled for 'stable' builds). I will probably remove it once IDLE2 is declared stable.
Hot path code is now cheap as chips.
IDLE / resume stuff reworked to use the S5P platform suspend code instead of specific assembly.
Blah blah blah. Probably loads more, but I forget, I've rewritten 90% of the code 2 or 3 times now, but I've learnt a lot.
Ignore the majority of the below, it's old and inaccurate. Perhaps I will update it sometime.
Any sensible questions regarding the code, ask in the thread.
No n00bs and no moronic questions please, think before post.
Patches and improvement suggestions are more than welcome, particularly now I think the code churn has stopped.
Credits and copyright of IDLE2 v0.3xx:
Originally, the majority was a port of code from Samsungs 2.6.32 P1000 kernel, hence Samsung retained the copyright because the changes were minor.
This is no longer the case as the current status of v0.3xx is that the vast majority of it, over 90%, is original code written by me as I have completely reworked and rewritten pretty much everything.
Describing it as a 'port' is not appropriate either, as it's not a port, it's a completely fresh implementation which has pretty much nothing in common with Samsungs LPAUDIO or Ezekeels didle, other than it achieves the same thing, arguably in a more robust and cheaper way, utilising as much common code as possible such as the platform suspend code.
IDLE2 was inspired by:
Samsungs P1000 kernel (my original port)
OMAP3/4 cpuidle
NVIDIA T2/3 cpuidle
S5PV210 TRM
There are a few portions of code in idle2.c which bear resemblance to the code in Samsungs 2.6.32 kernel, such as the defines and struct for the device checks, the memory allocation in idle2_post_init(), the gpio code in s5p_enter_idle2(), checks for activity in MMC/OneNAND et al, but the rest is entirely my work.
In short: The MMC & OneNAND activity check and the GPIO power down are Samsung code with modifications, but that is the extent of Samsung copyright.
Wilful kanging, not clearly giving proper credits and not contributing back is extremely unwelcome.
Open source is not about copying other peoples work, a principle which some developers don’t get.
The GPL was never designed for the purpose of copying code verbatim and riding on other peoples work, it was designed to allow freedom of code, a continual cycle of improvement and peer review, so consider that please and if you aren't prepared to work like that, perhaps consider the reasons why you are actually 'developing' and releasing stuff on here.
another awesome work by this awesome community. many thanks thalamus
teoserio said:
another awesome work by this awesome community. many thanks thalamus
Click to expand...
Click to collapse
You are very welcome.
I almost forgot...(lol)
If you want to try it out, right now, it's in my latest kernel release, which is available here. Info on my blog here.
Can you be so kind to update your first post and tell us how we use the patch files???
I would like to link to your thread from my tutorial how to compile a kernel.
This way we can teach more people to make kernels and they can make their own also.
djjonastybe said:
Can you be so kind to update your first post and tell us how we use the patch files???
Click to expand...
Click to collapse
There is a readme in the patch directory.
djjonastybe said:
Can you be so kind to update your first post and tell us how we use the patch files???
I would like to link to your thread from my tutorial how to compile a kernel.
This way we can teach more people to make kernels and they can make their own also.
Click to expand...
Click to collapse
It tells you how to use the patch files in the readme which is included in the same directory as the patches.
_thalamus said:
You are very welcome.
I almost forgot...(lol)
If you want to try it out, right now, it's in my latest kernel release, which is available here. Info on my blog here.
Click to expand...
Click to collapse
Okay i'll flash it later and report back with results
look's promising..
I checked and it works on the Jelly Bean. Android 4.1.1 AOSP
Jelly Bean i tapatalk
Astonishing work Thalamus. Ill be testing this as soon as possible, which means not now since its 4am and I just watched the new Batman.
Ill throw out some numbers as soon as I get some sleep, though I very much like some of the improvements you've made. I have high hopes.
Harbb said:
Astonishing work Thalamus. Ill be testing this as soon as possible, which means not now since its 4am and I just watched the new Batman.
Ill throw out some numbers as soon as I get some sleep, though I very much like some of the improvements you've made. I have high hopes.
Click to expand...
Click to collapse
Right on with that. Cannot wait to test this myself. It's a bit sad the development gets so far after the Nexus S gets "phased out" with the release of the Google Nexus. Not exactly its primetime, even though some releases here are top quality material. I cannot imagine someone would be deceived by all this, finally getting DI stable.
ALSO
You guys get the new Batman already? I'm jealous. Gotta wait until the 20th... *shakes fist*
Awesome contribution! I love seeing new kernel patches. Will try it out.
It seems I have a bug which breaks bluetooth audio streaming.
The good news, I know exactly what is causing it. The bad news, I don't really have any way of testing it because I don't own such hardware.
So, anyone who has got a bluetooth headset and can test a fix for me, please PM me.
So, the bluetooth issue is now fixed, thanks to Randomwalker for testing it so promptly.
IDLE2 version is now v0.130 and I have updated my kernel with the fix and released 3.0.37-18.
Info on the fix and kernel here.
When it's 100% stable I will try porting the patches to other devices as well.
djjonastybe said:
When it's 100% stable I will try porting the patches to other devices as well.
Click to expand...
Click to collapse
It is stable. Stability of idle2 is not an issue.
'Porting' won't be required, it should work on any S5PV210 device as is and S5PC110 devices with small alterations to the file paths / Kconfig. It's pretty generic. At the worst, you might have to fix a few conflicts, but that is about it.
The bugs I have fixed today were related to bluetooth audio streaming and the LED torch, neither were a reflection on the stability of the idle2 code, just things that were missed during testing, because myself and the people who tested for me can't test every corner case.
Very nice. Just have a few questions:
Is this a full stand alone kernel? Or like a patch you flash over your existing kernel to add this new feature?
Sorry if I don't make much sense, still kind of noob.
Sent from my Nexus S using Tapatalk 2
MrBigWaffles said:
Very nice. Just have a few questions:
Is this a full stand alone kernel? Or like a patch you flash over your existing kernel to add this new feature?
Click to expand...
Click to collapse
The patch is something you include in your code if you're compiling a kernel, it cannot be flashed over a kernel, like in a ROM.
There is however a kernel available which contains the patch, among others, which is also developed by _thalamus.
Sent from my Nexus S
on my i9023 and Remics rom it seems that there's more battery drain than INK (the version with DI by fear).
Btw I didn't try while listening music so I don't know if it is kernel related or something else
teoserio said:
on my i9023 and Remics rom it seems that there's more battery drain than INK (the version with DI by fear).
Btw I didn't try while listening music so I don't know if it is kernel related or something else
Click to expand...
Click to collapse
'seems that there's more battery drain' isn't massively helpful to be honest. More detail would be appreciated, such as some figures compared to a previous one of *my* kernels.
I'm not sure if there is an issue or not at the moment, looking at the time the device is spending in suspend makes me think that there isn't a problem, but if someone can show me that there is, I will look into it.
Rom Port Team Effort
Hello P880 community.
This post has the purpose to put together a group of users / developers, who are willing to participate into bringing a different set of roms into our community.
These set of roms that I'm thinking, can range from complete Sense ports to more customized and maybe less popular roms (like ColorOS, LiGux, FlymeOS, FluidUI, etc..).
What's valid on this thread:
- CM / AOSP (any base we already have) themed (like Samsung TouchUI, Optimus, Blur, etc..). So you can grab any rom (with author authorization), theme it (i mean, not just shove an apk as default theme, I mean neat theming ).
- Ports from other devices (evert port needs to have clear authors permission to port it).
- All users are very welcome, everyone can participate, users with porting / developing skills are needed as well.
The idea is simple, we're not going to use this thread to post the work, this is just a thread to talk about possible projects.
We can start by listing which devices are hardware compatible and the port is "easily" possible.
Roms that can be used as a base for eventual future ports.
CM10.2 - thanks to laufersteppenwolf for compiling this build promptly for this purpose
http://goo.im/devs/laufersteppenwolf/CM10.2//cm-10.2-20140305-UNOFFICIAL-p880.zip
- - - - -
I strongly recommend the use of MultiRom for testing ports and other roms. That way you can maintain your working rom and whenver feeling adventurous you can without going through the hassle of backup / restore / yada yada yada that we are all too familiar with.
http://forum.xda-developers.com/showthread.php?t=2655988
- - List of Devices with hardware similar / close / identical to the 4X - -
- HTC One X
- HTC One X +
- More ??
- Possible roms to port:
Right now would be nice to see a OEM rom, such a touchwiz or Sense
Work in Progress
N/A available
(awaiting sugestions
So, what do you guys think? ? Any users with good porting skills ? I know we have good developers! Ideas? Sugestions?
Write away
A few guides from XDA - They may not be all you need to get the job done, but a LOT of important information is written here. Don't forget to thanks their authors
Guides / Tutorials
How to Port Roms by @saywhatt
How to Port Manufacturer Rom. by @GalaxyUser
How to port Stock/GB/CM7/CM9/ICS/CM10/JB Based ROMs by @Peteragent5
PS - Every work that is possible to port and if someone decides to invest time in it, it needs explicit authors permission.
Sure if a few people want a particular rom i can bring it to our device, but i would much prefer helping first time rom builders do this own their own then they can maintain it also
JoinTheRealms said:
Sure if a few people want a particular rom i can bring it to our device, but i would much prefer helping first time rom builders do this own their own then they can maintain it also
Click to expand...
Click to collapse
Well, I though about some sort of "voting" to bring a "specific" rom.
Personally, I'd love to have Sense on our device. I had two HTC's before and I miss that Sense interface :b
But far as I'm aware, isn't an easy thing to port.
About your offer, this thread stands mostly with learning. The idea is everyone being able to contribute and more users start bringing roms as their first times. So, thank you so much for lending your help and know how, I'm sure we'll have a fine list of possible ports and then we can talk about how to port them over
Everyone can ask for help and the idea is to everyone who is able to - help.
I like the idea of this thread, but what would also be quite usefull is a list of available ROMs and their maintainer(s).
Also the list should include ROMs someone is working on ATM, so it cannot happpen that 2 devs are working on the same ROM
However, your idea is good, but porting a ROM not from sorce is quite hard, and might need some smali "hacking" in order to resolve bugs.
But well, we're a community, and I guess we can help each other if needed, right
laufersteppenwolf said:
I like the idea of this thread, but what would also be quite usefull is a list of available ROMs and their maintainer(s).
Also the list should include ROMs someone is working on ATM, so it cannot happpen that 2 devs are working on the same ROM
However, your idea is good, but porting a ROM not from sorce is quite hard, and might need some smali "hacking" in order to resolve bugs.
But well, we're a community, and I guess we can help each other if needed, right
Click to expand...
Click to collapse
That's correct! :good:
The main point is to learn helping each other who knows in a month or so, today's whiners are tomorrow's contributors
Jokes aside, the first post will be edited in order to structure and add information.
I'm gonna start with compatible devices (the ones that allow porting in a easy way). Ideas? Besides the HTC One X ? I'm guessing the grouper (N7 2012) besides having the same soc, doesn't have the same screen...
PS - (this would be better with an experienced porter) - Maybe we could start with a easy one, and go on from there
I know we have "how to port" threads all around xda ,but each port is different so we can't use "one hat to fit them all" ... or a ring to rule them all, so we should treat each port differently.
However.. I'm gonna put some xda links about porting to bring some light into the matter for who is "new" on this subject... or for whom's feeling adventurous and can't wait to have "their" rom on "our" device
Oh yes finally, have been waiting for a thread like this for a long time me as well would love to see a sense rom on this phone
cm/aosp roms are not that hard to port most of the time u only need the same screen resolution for it to work. (ported a nexus s touchwiz rom over to my old lg optimus 2x) but would have loved to see some oem roms ported over as well, even though it would be a lot harder to port over. but as a wonderful community as this is we might be able to pull it off
MidnightDevil said:
That's correct! :good:
The main point is to learn helping each other who knows in a month or so, today's whiners are tomorrow's contributors
Jokes aside, the first post will be edited in order to structure and add information.
I'm gonna start with compatible devices (the ones that allow porting in a easy way). Ideas? Besides the HTC One X ? I'm guessing the grouper (N7 2012) besides having the same soc, doesn't have the same screen...
PS - (this would be better with an experienced porter) - Maybe we could start with a easy one, and go on from there
I know we have "how to port" threads all around xda ,but each port is different so we can't use "one hat to fit them all" ... or a ring to rule them all, so we should treat each port differently.
However.. I'm gonna put some xda links about porting to bring some light into the matter for who is "new" on this subject... or for whom's feeling adventurous and can't wait to have "their" rom on "our" device
Click to expand...
Click to collapse
You can add the HOX+ to the list as well
About porting, you need to seperate it in two halfs, porting from source, and "winzipping". TBH, I'm no fas of winzipping at all, but some stuff (like sense or TW) can only be winzipped...
BTW, if you need a 2nd/3rd post, just let me know
Personally, I'd like to see a GFlex or even better, a G2 (/mini) ROM for our phone (KitKat, of course )
This thread has potential
I'm new to this forum,so i dont know whats going on about roms,i see there are few devs working full time.
I think this is the best way to go: Port ALL open source roms,such as we have already,but we need them all.
Second,make a badass kernel,with all features and customizations,possibly 3.4.
Third,and just a suggestion,Make a community ROM?
I really like this thread,and i even more like this OX4 community,you all get along,and i've missed that,i was on a forum that has no frendly people whatsoever.
And,about the roms,the idea is awesome,but i always think of the clash of clans rule,max everything out before going on a higher level.
Sent from my LG-P880 using XDA Premium 4 mobile app
Regarding stock roms, it's an interesting thing, but I'm guessing stock roms are more trouble to port comparing to AOSP or CM.
I remember on the HTC Sensation forums the headaches sense brought to many developers and porters, the bunch of files that needed to be edited, kernel changes (aosp kernel is different from stock / sense kernel in that case).. so Stock roms are maybe harder to port fully.
Right now we have some apks from the G2 (lock screen, messaging, etc..), maybe someone will port some things from the Flex, but the whole base.. hum
@DeHuMaNiZeD , thanks for your reply
The other roms based of AOSP and CM, in my opinion, unless they're different (modded, themed, customized - etc..) but if not, if they are "clean" roms with no changes, then - we have them already I believe you'll agree. (Unless the idea is to test something).
A 3.4 kernel would be something, but perhaps a developer can shed some light here - what benefits would we have from a 3.4 kernel ?
A community rom is indeed long due. This thread is a different subject because it's about *several* roms, ports and tutorials, maybe you would like to create a thread here on General about that? You can start with votes (i believe it's a proper way to do it) with which base should we use (Cm, AOSP, Stock, etc..), included apps (or not), possibly aroma maybe and so on
DeHuMaNiZeD said:
This thread has potential
I'm new to this forum,so i dont know whats going on about roms,i see there are few devs working full time.
I think this is the best way to go: Port ALL open source roms,such as we have already,but we need them all.
Second,make a badass kernel,with all features and customizations,possibly 3.4.
Third,and just a suggestion,Make a community ROM?
I really like this thread,and i even more like this OX4 community,you all get along,and i've missed that,i was on a forum that has no frendly people whatsoever.
And,about the roms,the idea is awesome,but i always think of the clash of clans rule,max everything out before going on a higher level.
Sent from my LG-P880 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Well, this sounds quite good, but the real problem is: this is a hell lot of work. Also, it needs resources. The sourcecode of a ROM is ~25-30GB. When it's compiled it's about double the size, and takes my PC (8 cores @ 4GHz) about 75Min to compile. Not to mention the time 'til the sources are Downloaded. My 500GB HDD is near to its limit very soon, so sooner or later I will need a new HDD, then I might be able to get another ROM ported, but right now, hard...
Also, why do you need a 3.4 kernel?
MidnightDevil said:
Regarding stock roms, it's an interesting thing, but I'm guessing stock roms are more trouble to port comparing to AOSP or CM.
I remember on the HTC Sensation forums the headaches sense brought to many developers and porters, the bunch of files that needed to be edited, kernel changes (aosp kernel is different from stock / sense kernel in that case).. so Stock roms are maybe harder to port fully.
Right now we have some apks from the G2 (lock screen, messaging, etc..), maybe someone will port some things from the Flex, but the whole base.. hum
@DeHuMaNiZeD , thanks for your reply
The other roms based of AOSP and CM, in my opinion, unless they're different (modded, themed, customized - etc..) but if not, if they are "clean" roms with no changes, then - we have them already I believe you'll agree. (Unless the idea is to test something).
A 3.4 kernel would be something, but perhaps a developer can shed some light here - what benefits would we have from a 3.4 kernel ?
A community rom is indeed long due. This thread is a different subject because it's about *several* roms, ports and tutorials, maybe you would like to create a thread here on General about that? You can start with votes (i believe it's a proper way to do it) with which base should we use (Cm, AOSP, Stock, etc..), included apps (or not), possibly aroma maybe and so on
Click to expand...
Click to collapse
For stock ROMs to work, it's your best bet to use AOSP as your base, and then look for what's missing/broken. This, however, means you need an AOSP base first to work with. And AOSP is not always the easiest thing to get properly running.
About the benefits of an 3.4 kernel: None IMO. All you get is a higher version-number, and that's it. We actually already have some 3.4 features backported, and also tweaked the 3.1 kernel quite a lot. So the actual benefits are all in your head (well, except you count bugs as benefits )
Community ROM? Meh, what for? We have so many ROMs already, so everyone should find the one that suits him/her best
BTW: Thread stuck
laufersteppenwolf said:
Well, this sounds quite good, but the real problem is: this is a hell lot of work. Also, it needs resources. The sourcecode of a ROM is ~25-30GB. When it's compiled it's about double the size, and takes my PC (8 cores @ 4GHz) about 75Min to compile. Not to mention the time 'til the sources are Downloaded. My 500GB HDD is near to its limit very soon, so sooner or later I will need a new HDD, then I might be able to get another ROM ported, but right now, hard...
Also, why do you need a 3.4 kernel?
For stock ROMs to work, it's your best bet to use AOSP as your base, and then look for what's missing/broken. This, however, means you need an AOSP base first to work with. And AOSP is not always the easiest thing to get properly running.
About the benefits of an 3.4 kernel: None IMO. All you get is a higher version-number, and that's it. We actually already have some 3.4 features backported, and also tweaked the 3.1 kernel quite a lot. So the actual benefits are all in your head (well, except you count bugs as benefits )
Community ROM? Meh, what for? We have so many ROMs already, so everyone should find the one that suits him/her best
BTW: Thread stuck
Click to expand...
Click to collapse
Why dont you set up that build server,i think they're cheap atm,or someone could borrow you? It would take a lot less time and effort. that's why i think offical rom support is important,once it's merged to the build bot,its their responsibility.
Sent from my LG-P880 using XDA Premium 4 mobile app
DeHuMaNiZeD said:
Why dont you set up that build server,i think they're cheap atm,or someone could borrow you? It would take a lot less time and effort. that's why i think offical rom support is important,once it's merged to the build bot,its their responsibility.
Sent from my LG-P880 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
It's not as easy as you might think
I do have access to a buildserver, however I only have 100GB as it's a shared one, so this is genious for official builds, or quick tests/ports. But it isn't ideal for the long terms.
Also, having it official doesn't mean you're done you need to update it, and also fix it when it's broken. 'cause when it's broken, it can mess up the whole build process of the buildbot
But in general, you're right, having it official does help a lot
{fd}ware said:
Does anyone of you have a link to the latest CM10.2 (Android 4.3) for our device?
It seems like it's not anymore on get.cm and I wanted to start porting a TouchWiz (Note 3) ROM to our phone when I have free time
Click to expand...
Click to collapse
I can't find them either, but I'm on a tablet so I can't look properly.
@laufersteppenwolf, do you have any *spare* 4.3 build?
MidnightDevil said:
I can't find them either, but I'm on a tablet so I can't look properly.
@laufersteppenwolf, do you have any *spare* 4.3 build?
Click to expand...
Click to collapse
LOL, no, I do not, but gimme a few hours and I'll have one
Syncing right now
laufersteppenwolf said:
LOL, no, I do not, but gimme a few hours and I'll have one
Syncing right now
Click to expand...
Click to collapse
Thank you
{fd}ware said:
BTW, did anyone tried to port a ROM this way? http://forum.xda-developers.com/showthread.php?t=2245786
Click to expand...
Click to collapse
Nope, I actually never "winzipped" a ROM
Lot of things to comment on here. Very good initiative I have to admit. I'm sure I'll have more ideas as the discussion evolves.
Similar hardware: You can add HOX+ as laufer said. Very minor differences are there only.
What I would personally prefer is TouchWiz, at least Nature UX 2.0, but new S5 UI is also really awesome. I liked Sense till 4.5, but 5.0+ versions are now out of my 'inner circles'. Especially what I don't like is the UI.
Few suggestions:
FlymeOS (from Meizu MX) - I got 2.0 booting last summer, but had touchkey issues (they were freezing the device lol) and never released it. Nobody ever booted 2.0+ on other Android devices yet.
Porting LG roms might be the best start, I think porting full Optimus G system wouldn't be that hard. Just a pain in the *ss merging process.
What we mainly need is same screen size (unless you wanna resizing 100+ apps ). Similar SoC is a good extra, but that's very limited. Also, it's better to avoid Qualcomm SoCs to port from, it's extremely hard, there are a lot of code changes in low-level code which just make the device get into deep segfault cycles. :cyclops: Even Exynos is easier to port from, trust me. I got SGS3 leaked 4.2 booting on the O4X last autumn.
Big issue we have to note: In 4.2, Google radically changed graphics libraries code. We have old, 4.1.2 blobs and those need hacks in libgui.so and libsurfaceflinger.so to function properly (in 4.4+ libEGL.so, libGLES_v1_CM.so and libGLES_v2.so also need a change). Here comes the problem: Manufacturers do change these libraries, mainly adding Wi-Fi display and HDMI support code which other blobs rely on. Of course we can't just replace these libs, graphics wouldn't function that way. Either we have to guess those function signatures and reimplement some stub in the code, or use new blobs, i.e. what I did in Omni. But y'all now those are not perfect _yet_.
Regarding newer kernels: If, I emphasize, IF it's properly ported, it would cause a noticeable effect on overall performance, battery life, etc. What do I mean by proper porting: All machine-specific code must be updated to Nvidia/Google upstream, no excuses! I don't say anything for sure, I didn't check it much, but kholk didn't do this merge. His kernel still uses 3.1 files with slight modifications to be 3.4-compatible. What I mean would be a very long and painful process, but would surely benefit after all. 3.4 has no Android branch, mainline Nvidia Tegra kernel does only have Linux support, it might be even harder. 3.10 is maintained by Google for Android, issues I have found so far: No graphics driver support for T2 and T3, have to forward-port it and I didn't find core Android components like wakelocks, earlysuspend, etc. Weird.
A little related story: I initially started working on MultiROM so I can test and port different roms while I can keep a stable rom for myself and there'd be no need for reflash then. That's what I can suggest. Use MultiROM, it has so many capabilities! Maybe it's better with kernel sharing so you don't have to wait for hardboot on every reboot (which one needs a lot if porting). @MidnightDevil you could add this to the OP maybe.
MidnightDevil said:
I can't find them either, but I'm on a tablet so I can't look properly.
@laufersteppenwolf, do you have any *spare* 4.3 build?
Click to expand...
Click to collapse
Here you are! Compiled this because wanted to start porting from Note 2, but finally worked on Omni more and abandoned it.
{fd}ware said:
BTW, did anyone tried to port a ROM this way? http://forum.xda-developers.com/showthread.php?t=2245786
Click to expand...
Click to collapse
That's way too generic unfortunately.
Quick suggestion for you port: Use Note 2 base with Note 3 features. Note 2 has the same resolution and you won't need to resize.
Adam77Root said:
Lot of things to comment on here. Very good initiative I have to admit. I'm sure I'll have more ideas as the discussion evolves.
Similar hardware: You can add HOX+ as laufer said. Very minor differences are there only.
What I would personally prefer is TouchWiz, at least Nature UX 2.0, but new S5 UI is also really awesome. I liked Sense till 4.5, but 5.0+ versions are now out of my 'inner circles'. Especially what I don't like is the UI.
Few suggestions:
FlymeOS (from Meizu MX) - I got 2.0 booting last summer, but had touchkey issues (they were freezing the device lol) and never released it. Nobody ever booted 2.0+ on other Android devices yet.
Porting LG roms might be the best start, I think porting full Optimus G system wouldn't be that hard. Just a pain in the *ss merging process.
What we mainly need is same screen size (unless you wanna resizing 100+ apps ). Similar SoC is a good extra, but that's very limited. Also, it's better to avoid Qualcomm SoCs to port from, it's extremely hard, there are a lot of code changes in low-level code which just make the device get into deep segfault cycles. :cyclops: Even Exynos is easier to port from, trust me. I got SGS3 leaked 4.2 booting on the O4X last autumn.
Big issue we have to note: In 4.2, Google radically changed graphics libraries code. We have old, 4.1.2 blobs and those need hacks in libgui.so and libsurfaceflinger.so to function properly (in 4.4+ libEGL.so, libGLES_v1_CM.so and libGLES_v2.so also need a change). Here comes the problem: Manufacturers do change these libraries, mainly adding Wi-Fi display and HDMI support code which other blobs rely on. Of course we can't just replace these libs, graphics wouldn't function that way. Either we have to guess those function signatures and reimplement some stub in the code, or use new blobs, i.e. what I did in Omni. But y'all now those are not perfect _yet_.
Regarding newer kernels: If, I emphasize, IF it's properly ported, it would cause a noticeable effect on overall performance, battery life, etc. What do I mean by proper porting: All machine-specific code must be updated to Nvidia/Google upstream, no excuses! I don't say anything for sure, I didn't check it much, but kholk didn't do this merge. His kernel still uses 3.1 files with slight modifications to be 3.4-compatible. What I mean would be a very long and painful process, but would surely benefit after all. 3.4 has no Android branch, mainline Nvidia Tegra kernel does only have Linux support, it might be even harder. 3.10 is maintained by Google for Android, issues I have found so far: No graphics driver support for T2 and T3, have to forward-port it and I didn't find core Android components like wakelocks, earlysuspend, etc. Weird.
A little related story: I initially started working on MultiROM so I can test and port different roms while I can keep a stable rom for myself and there'd be no need for reflash then. That's what I can suggest. Use MultiROM, it has so many capabilities! Maybe it's better with kernel sharing so you don't have to wait for hardboot on every reboot (which one needs a lot if porting). @MidnightDevil you could add this to the OP maybe.
Here you are! Compiled this because wanted to start porting from Note 2, but finally worked on Omni more and abandoned it.
That's way too generic unfortunately.
Quick suggestion for you port: Use Note 2 base with Note 3 features. Note 2 has the same resolution and you won't need to resize.
Click to expand...
Click to collapse
Dang, you've beaten me but mine's as fresh as it could be
HERE you guys go, for all who need the newest CM10.2
laufersteppenwolf said:
Dang, you've beaten me but mine's as fresh as it could be
HERE you guys go, for all who need the newest CM10.2
Click to expand...
Click to collapse
Just don't delete the sources, you might need them in the close future.
I think we should create a schedule about what to do. As you all know, good buildings all have good grounding. So let's get started from the very beginning I say. First fix remaining bugs in MultiROM, then create a unified kernel so users don't have to choose. Very likely this is not possible as people think different so just make all kernels hardboot compatible. After these we have a solid base for starting all the work. Of course this cannot be done if not everybody is involved. Both devs and users should share a part in this magnificent journey.
(High expectations, I know. )
Sent from my OmniROM-powered LG Optimus 4X HD