Kernel Assistance - Vibrant Android Development

Im currently working on the next release for Team Whiskey. I have the kernel all ready to go, and everything working great. (with the exception of GPS)
Right now, the only big issue is the Vol Key mapping. They are reversed, so Up = Down and Down = Up.
I've tried just about everything I could think of to get it to work, but either A. it doesn't, or B. it breaks the mapping completely, and you have to press both vol keys to get the vol to turn up.
I am attaching the original s3c-keypad.c file where the mapping lies.
Kernel Devs,
Any help is appreciated. I know Eugene has this fixed, but he's keeping tight lipped about it.
The attached file is from the I9K Froyo source.

Could you reverse the contents of the volume up and down static methods?

in a linux shell:
diff kernelsource1.tar kernelsource2.tar
and go from there...

dattaway said:
in a linux shell:
diff kernelsource1.tar kernelsource2.tar
and go from there...
Click to expand...
Click to collapse
......
Eclair vs Froyo...for 2 different devices. The whole kernel source is different.
I9K source is building off of mach-sp5cv210
Vibrant Eclair source builds from mach-sp5c110
richan90 said:
Could you reverse the contents of the volume up and down static methods?
Click to expand...
Click to collapse
tried. thats when I got the issue where you had to press both down and up to get to go up.

krylon360 said:
......
Eclair vs Froyo...for 2 different devices. The whole kernel source is different.
I9K source is building off of mach-sp5cv210
Vibrant Eclair source builds from mach-sp5c110
tried. thats when I got the issue where you had to press both down and up to get to go up.
Click to expand...
Click to collapse
Did down work in that case?

it was a hit or miss, and when you hit the keys, the vol either went all the way up, or all the way down. no in between.

Hmm.. I'm just throwing random ideas out there, but in line 281:
INPUT_REPORT_KEY(dev, 42, key_status ? 0 : 1);
I'm not really sure what parameter corresponds to the 42, but in all the volume up methods its 42, while in volume down its 58.
There's a few other places in the code where this happens too. Sorry if this is totally off base. My experience in programming is very very minimal.

Sorry to be off topic, but your avatar really makes me want to _not_ donate to you. No offense.

@number, yeah I need to change it. That pic was taken about 5 years ago. Ill change it today.
Sent from my Fusion v2.0 Custom Froyo Kernel using the XDA app.

I'm just curious, what's the difference between s3c_keygpio_vol_up_isr and s3c_keygpio_vol_up26_isr?
I only ask because I noticed that s3c_keygpio_vol_up26_isr is the one that's actually referenced again down on line 359.
If this is way off base I'm perfectly ok with simply being ignored

MWBehr said:
I'm just curious, what's the difference between s3c_keygpio_vol_up_isr and s3c_keygpio_vol_up26_isr?
I only ask because I noticed that s3c_keygpio_vol_up26_isr is the one that's actually referenced again down on line 359.
If this is way off base I'm perfectly ok with simply being ignored
Click to expand...
Click to collapse
not way off. I tried commenting out vol_up26 and setting it to the vol_up_isr info (3)
and the disabled my vol down button.
Vol up still acted as vol down.

Hmm. I assume simply swapping the contents of the statics s3c_keygpio_vol_up26_isr and s3c_keygpio_vol_down_isr is a no go as well?

Doesn't the captivate have froyo source? If so, have you tried to compare that to the i9000?

krylon360 said:
Kernel Devs,
Any help is appreciated. I know Eugene has this fixed, but he's keeping tight lipped about it.
The attached file is from the I9K Froyo source.
Click to expand...
Click to collapse
I think it's a little unfair to characterize eugene in any way as tight lipped. For one, there wouldn't be any other ROMs out for the Vibrant if it weren't for him. Every ROM sombionix or anyone else released for the Vibrant started with eugene's base. Secondly, Team Whiskey hasn't published the source for the Core kernel, or even talked about compiler optimizations, or even what governor is used. That kinda seems tight lipped to me. It'd be nice, educational even, to see what the significant differences are between this kernel and JACs and Kingklick's, or how the kernel was 'optimized' specifically for the bionix ROMs.
That said, xcaliburinhand actually does publish the source for the Captivate kernels he makes, so you might want to take a look through his git.

The volume keys mapping can be fixed by comparing the source with vibrant. you just need to look careful for the correct file and lines to change.

We have already publicy stated we will release the source for everything we do once it is stable.
If you want to know what we do, just ask. I didn't work on core, that was vb and morfic.
When I said eugene was being tight lipped, telling someone that its in the source and that's it, that's pretty tight lipped to me. I have yet to see and source from eugene or jac.
I know x has his source for the cap port on git. The cap and i9k are the same when it comes to the vol key mapping.
Sent from my Fusion v2.0 Custom Froyo Kernel using the XDA app.

krylon360 said:
not way off. I tried commenting out vol_up26 and setting it to the vol_up_isr info (3)
and the disabled my vol down button.
Vol up still acted as vol down.
Click to expand...
Click to collapse
I don't think the 's3c_keygpio_vol_up_isr' interrupt handler is used since is was never registered (at least not in this file anyway).
my guess is reading register 'S5PV210_GPH3DAT' probably returns key press or release.
try changing line 281
INPUT_REPORT_KEY(dev, 42, key_status ? 0 : 1);
in the 's3c_keygpio_vol_up26_isr' handler to
INPUT_REPORT_KEY(dev, 58, key_status ? 0 : 1);
then change line 296
INPUT_REPORT_KEY(dev, 58, key_status ? 0 : 1);
in the 's3c_keygpio_vol_down_isr' handler to
INPUT_REPORT_KEY(dev, 42, key_status ? 0 : 1);

Thanks coach. This actually looks like it might work. Ill give this a shot before I head to work in the morning. My wife is using the pc right now so I can't try it out.
Sent from my Fusion v2.0 Custom Froyo Kernel using the XDA app.

glitterballs said:
I think it's a little unfair to characterize eugene in any way as tight lipped. For one, there wouldn't be any other ROMs out for the Vibrant if it weren't for him. Every ROM sombionix or anyone else released for the Vibrant started with eugene's base. Secondly, Team Whiskey hasn't published the source for the Core kernel, or even talked about compiler optimizations, or even what governor is used. That kinda seems tight lipped to me. It'd be nice, educational even, to see what the significant differences are between this kernel and JACs and Kingklick's, or how the kernel was 'optimized' specifically for the bionix ROMs.
That said, xcaliburinhand actually does publish the source for the Captivate kernels he makes, so you might want to take a look through his git.
Click to expand...
Click to collapse
haha...I laugh at you. Get your facts straight before you write nonsense. For your information, the only 'base' of eugenes I used was from the original JFD. As for a 'base' being used, that's the ONLY thing that was used. All of the mods, framework, and other edits within my rom were done or implemented by me. The way he had his 'base' set up for JFD was exactly how myself or any other dev would have set it up had we done it first. All of my other builds from JI2 and up, were done BY ME. In fact, if you look at rom dates, you'll see that I was the first one to release a rom using the official OTA JI6 files.
Sorry to have to defend myself, but I'm sick of people thinking we kang eugenes work. All of our work post JFD has been done by us, INCLUDING our new kernels we've released in recent days. That was all done from source, BY US. Thanks!

sombionix said:
haha...I laugh at you. Get your facts straight before you write nonsense. For your information, the only 'base' of eugenes I used was from the original JFD. As for a 'base' being used, that's the ONLY thing that was used. All of the mods, framework, and other edits within my rom were done or implemented by me. The way he had his 'base' set up for JFD was exactly how myself or any other dev would have set it up had we done it first. All of my other builds from JI2 and up, were done BY ME. In fact, if you look at rom dates, you'll see that I was the first one to release a rom using the official OTA JI6 files.
Sorry to have to defend myself, but I'm sick of people thinking we kang eugenes work. All of our work post JFD has been done by us, INCLUDING our new kernels we've released in recent days. That was all done from source, BY US. Thanks!
Click to expand...
Click to collapse
+1
Exact SAME thing happened to me when I first released Axura.
Yeah, Eugene released a Froyo version based on JPM.. But I made a version based on JPA. Someone had the nerves to come & tell me that I just released a themed version of his ROM.
Once again, I am one step above him using JPO. Please people, don't start saying someone is the ONLY developer here. Yeah, he is a good dev.. But so are the others. Sorry to get off topic there, but I had to COMPLETELY agree with Sombionix on that.
Now to get back on topic.. What coachmai posted earlier would probably work.. So go ahead and try that

Related

Compatible JPM Froyo Kernel + Lagfix from i9000 Forums

Hey guys! Hope I don't get flamed for posting in development but it just doesn't seem like this should be in general... Anyways, sztupy over in the i9000 forums developed a universal lagfix kernel that is compatible with Eugene373's JPM Froyo rom. You are able to convert your partitions [including /dbdata and /cache] to EXT4, EXT2, and JFS.
The original forum can be found here - http://forum.xda-developers.com/showthread.php?t=814228
I have flashed this and have successfully converted my partitions using the EXT4 Advanced and Overkill options and back to RFS. All buttons work in recovery [yes including the power button] BUT when using your phone HOME and BACK both act as HOME. I just did this today so I cannot comment on battery life. One thing that is pretty cool though is this has back light notification built into it and I can confirm it works. I made a flashable zip for the latest build 0.3 and have flashed it successfully.
Disclaimer: I am not responsible for anything you do to your device. So proceed at your own risk.
ENJOY!
The backlight notification, does it stay on persistently, once you get a message, or does it go on and off? Example, if I get a message while I'm sleeping are my leds going stay lit all night?
Sent from my SGH-T959 using Tapatalk
eugenes kernel is the only reason why we have all the buttons working. If you flash a different kernel it will mess up back and home and break things. Don't people read anymore??
If any thing we should be flashing any rom from the i9000 then eugenes kernel
Sent from my vibrant
blackerwater said:
eugenes kernel is the only reason why we have all the buttons working. If you flash a different kernel it will mess up back and home and break things. Don't people read anymore??
If any thing we should be flashing any rom from the i9000 then eugenes kernel
Sent from my vibrant
Click to expand...
Click to collapse
I've not seen anybody report anything else breaking minus the key mapping. Also, calm down. I'm just interested in the complete rfs replacement w/ ext4 and backlight notify. Why does it bother you if people want to satisfy curiosity?
Sent from my SGH-T959 using Tapatalk
Sorry I didn't mean to be harsh. But i just keep seeing the same questions over and over and misinformation . Thats all.
Sent from my vibrant
It's cool.
Sent from my SGH-T959 using Tapatalk
has anyone asked eugene if he's thought about implementing this in his kernel?
blackerwater said:
eugenes kernel is the only reason why we have all the buttons working. If you flash a different kernel it will mess up back and home and break things. Don't people read anymore??
If any thing we should be flashing any rom from the i9000 then eugenes kernel
Sent from my vibrant
Click to expand...
Click to collapse
You r right, I see too many people jumping to flash "anything", without taking precautions, and after the fact running crazy to fix the mess. Giving this kind of advice, while is not polite, it is wise....
Sent from my SGS TMo Vibrant with
FFC (Yes, front cam)
Froyo (Yes, Android 2.2)
Full Flash 10.1 (Yes, flash videos, hulu, and so on)
And Multitasking... For real
Having an iAttack yet?
Using XDA App
gagb1967 said:
You r right, I see too many people jumping to flash "anything", without taking precautions, and after the fact running crazy to fix the mess. Giving this kind of advice, while is not polite, it is wise....
Sent from my SGS TMo Vibrant with
FFC (Yes, front cam)
Froyo (Yes, Android 2.2)
Full Flash 10.1 (Yes, flash videos, hulu, and so on)
And Multitasking... For real
Having an iAttack yet?
Using XDA App
Click to expand...
Click to collapse
It's funny over in eugene373's people were talking about this lagfix, and it was suggested to start a new thread to avoid clutter. Good advice. Now the only people posting here want nothing to do with said lagfix.???
XDA is a weird place.
Sent from my SGH-T959 using Tapatalk
billydroid said:
It's funny over in eugene373's people were talking about this lagfix, and it was suggested to start a new thread to avoid clutter. Good advice. Now the only people posting here want nothing to do with said lagfix.???
XDA is a weird place.
Sent from my SGH-T959 using Tapatalk
Click to expand...
Click to collapse
I think you got it wrong. We are not saying no to do things or experiment. Is just there are people that don't understand exactly what they are doing, and follow this threads, and do the changes without precautions.
One thing is to experiment, but is important to point out what the consecuences maybe.
Without a back button working, it really makes this phone a pain in the a$$ to navigate!!! especially when in your messaging or facebook app. Not really worth flashing till one of the vibrant devs can fix the back button in one of these lag fix kernals.
deviusdragger said:
Without a back button working, it really makes this phone a pain in the a$$ to navigate!!! especially when in your messaging or facebook app. Not really worth flashing till one of the vibrant devs can fix the back button in one of these lag fix kernals.
Click to expand...
Click to collapse
The no back button is proving annoying for sure. Just wanted to post an update. I converted to Advanced JFS successfully and got a quad score of 1560. One other thing that does seem to be broke [as expected] is media sound. Ringtones still work. The backlight notification has been working great! However it does not seem to ever turn off [can disable it in recovery]. Battery life seems fairly decent so far. Think I'll give Overkill JFS a go and see how it runs. Would definitely be nice if this could be compiled into Eugene's kernel. Hopefully more will come of this...
I'm going to take a look at their kernel source and the source that eugene has for his ROM and see what I can do between the two, maybe I will be able to get this running on the Vibrant with correct keymapping
gothdroid said:
I'm going to take a look at their kernel source and the source that eugene has for his ROM and see what I can do between the two, maybe I will be able to get this running on the Vibrant with correct keymapping
Click to expand...
Click to collapse
That would be awesome if you can get it to work! If you need someone to test it PM me ANYTIME. Good luck!

[REQ} Voodoo for DL30

I don't think I"m the only one looking for this, but I"m sure it will happen at some point, till then I have DL09.
Cheers all!
Crap, wrong thread... I should have put this in Development?
General.
Sent from my SCH-I500 using XDA App
Also they don't need a request for every thing just give some timeeeeeeeee patience is a virtue
jt is working on it
this is kinda ridiculous...might as well go for broke:
i request gingerbread with a 9000mhz voodoo45 kernel that runs on solar power
lmao nitsuj17
nitsuj17 said:
this is kinda ridiculous...might as well go for broke:
i request gingerbread with a 9000mhz voodoo45 kernel that runs on solar power
Click to expand...
Click to collapse
Well, then want it themed by nitsuj17...cause he is the bomb.
nitsuj17 said:
this is kinda ridiculous...might as well go for broke:
i request gingerbread with a 9000mhz voodoo45 kernel that runs on solar power
Click to expand...
Click to collapse
I'll have it to you yesterday
imnuts said:
I'll have it to you yesterday
Click to expand...
Click to collapse
we can always count on you
nitsuj17 said:
this is kinda ridiculous...might as well go for broke:
i request gingerbread with a 9000mhz voodoo45 kernel that runs on solar power
Click to expand...
Click to collapse
Pssst, whatever, if we're going for broke, then I'm gonna be pissed if JT doesn't have a Honeycomb Superclean ROM, Voodoo OC'd to 1500 with solar and moonlight powered, so I don't even need a battery, ready by tomorrow..... I mean, come on, they've had the Honeycomb SDK for what, like 4 days now.......
Wasn't trying to upset people, if I could have deleted I would have....
Posted from Super Clean, DL09 Fascinate with Voodoo 5 kernel.
DarthCivicus said:
Wasn't trying to upset people, if I could have deleted I would have....
Posted from Super Clean, DL09 Fascinate with Voodoo 5 kernel.
Click to expand...
Click to collapse
It's not just you though...
How would voodoo be ported to DL30? I am just curious on what differences there are? is it just the libs that would need to be changed or what? I am not trying to request it or anything, I am actually just curious. I know the devs will release it when they feel it is good to go to the masses.
Where's the setting to print money?
Sent from my SCH-I500 using XDA App
Daswolven said:
Where's the setting to print money?
Sent from my SCH-I500 using XDA App
Click to expand...
Click to collapse
Mine builds me an island and then turns into a jet and f***ing flies me there.
DarthCivicus said:
Wasn't trying to upset people, if I could have deleted I would have....
Posted from Super Clean, DL09 Fascinate with Voodoo 5 kernel.
Click to expand...
Click to collapse
The only problem is that waaay too many people are requesting EVERYTHING although its only been a few days since 2.2 was leaked/released. Hell one person was asking about Android 3.0.
Kaze105 said:
The only problem is that waaay too many people are requesting EVERYTHING although its only been a few days since 2.2 was leaked/released. Hell one person was asking about Android 3.0.
Click to expand...
Click to collapse
requests, usually, are fine...the issue is when something new comes out...everyone wants the exact theme, enhancements, mods, etc they had on their previous setup...this simply isnt possible overnight or even really soon.
relative to other devices, the fascinate has a smaller amount of people that work on it some capacity...dev wise we have 5-6 people that build roms/kernels and look at what theyve put out already in a few short days.
theme wise we dont have the bgills, jsinlegacys, etc of the android world that truly know frameworks/apks inside out...its mostly a few of us that have a relatively good idea of what we're doing porting themes, and making some of our own (well alternate gb versions or something lol)...if i wanted to for example, i could prolly just do quick and messy ports of the frameworks of every theme ive done before in 2 days or something...but i tend to go beyond that with apps and such like others do here
so on my end at least (and i think i can speak for a few others) stuff will come out when its ready...now i understand that themes vacated by people no longer around like retrokid cause some anxiety as it seems no one is working on them...but if theyre popular enough people pick them up (i took on revolution)...so give it a few weeks guys
Is a voodoo port even possible on the .32 kernel before samsung releases the source? Since we only have a leak I imagine it will be a bit before official release of the .32 source for the fascinate. I'm loving DL30 so far but definitely notice some of the lag now that voodoo is gone. But as nitsuj17 said this should be expected anytime you upgrade to a new release. Gotta give our excellent devs some time to port.
prometheus1010 said:
Is a voodoo port even possible on the .32 kernel before samsung releases the source? Since we only have a leak I imagine it will be a bit before official release of the .32 source for the fascinate. I'm loving DL30 so far but definitely notice some of the lag now that voodoo is gone. But as nitsuj17 said this should be expected anytime you upgrade to a new release. Gotta give our excellent devs some time to port.
Click to expand...
Click to collapse
jt is working on voodoo from what i gather...i wouldnt put it past him to get it to work...its apparently one of the few things *possible* is still really hard to do...without source
It's been discussed before. You can use a binary kernel to build a custom version using config.gz, provided it was included with the kernel build. Without that, it would be almost impossible.
Ultimately, having the source directly from Samsung is the best way to get a custom kernel.
I really can't wait for some of the 2.3 kernel stuff to start trickling down, since it has ext4 built-in natively. Then we won't need voodoo, it will just be that way already.

[Unofficial][ROM]CM7.1 Port to DS7....work in progress

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.

i dont understand, why so many ics roms based on an alpha?[rant]

already about 5 ics roms not counting the cm9 alpha, why??
they all have the same bugs
they all have the same things working
super ics kangorama?
http://forum.xda-developers.com/showthread.php?t=1360567
koush's + launcher pro added..
nexus mv ics?
http://forum.xda-developers.com/showthread.php?t=1364411
koush's + glados kernel + v6 supercharger
ultimate ics?
http://forum.xda-developers.com/showthread.php?t=1363765
koush's + some extra wall papers + file explorer
all these things are just a completely alpha ics build with some hacks thrown in.. why?? why not just make a post in the ics thread (either by kwiboo or koush) saying "hey guys use launcher pro if you feel its buggy" or "here is link to glados kernel" instead of making "New ultimate sweet fast ICS rom" when all you are doing is downloading one of the actual source built ics roms and opening it with 7zip and dropping in a new boot.img in there then asking for donations :/
/rant
It is no different than the numerous GB/CM based ROMs. Who cares?
Bounced off a tower to a forum near you!
I think that He ( OP ) won't be happy until they say Beta.. its alpha for a reason. so many bugs much more than beta. just sit happy with GB and give it time. I rushed it and lost the ability for Google Wallet, nothing can fix what went wrong with my phone.
xjreyes said:
I think that He ( OP ) won't be happy until they say Beta.. its alpha for a reason. so many bugs much more than beta. just sit happy with GB and give it time. I rushed it and lost the ability for Google Wallet, nothing can fix what went wrong with my phone.
Click to expand...
Click to collapse
What happened? I had wallet set up and ready to go, tried it at rite aid and wouldn't go through...
Sent from my Nexus S using XDA App
these people couldn't be taking part in a hobby for them, could they be just trying to learn the ins and outs of android, heck they couldn't even be kids learning to code and all are getting excited to show off what they complied.
Last time I checked you were not required to flash every rom in the Dev section. So lets take a step back I don't like miui nothing wrong with it but should I be complied to start a thread asking why we have topics about when I don't care for it.
icecoldbong said:
/rant
Click to expand...
Click to collapse
You said it....
Chill out. We have to get AOSP working bug-free in the first place, then they'll start looking different. Even CM9 doesnt have any CMsettings or anything special. We're sorry that something that we're beating Google at (ICS release for NS) currently is not to your standards.
In due time.....in due time.
I see where the OP is coming from, but I disagree. The fact that the devs work hard to bring the OS to our devices is pretty appreciated. They pretty much do Google's work for free by modifying the code.
Sent from my Nexus S using XDA App
icecoldbong said:
already about 5 ics roms not counting the cm9 alpha, why??
they all have the same bugs
they all have the same things working
super ics kangorama?
http://forum.xda-developers.com/showthread.php?t=1360567
koush's + launcher pro added..
nexus mv ics?
http://forum.xda-developers.com/showthread.php?t=1364411
koush's + glados kernel + v6 supercharger
ultimate ics?
http://forum.xda-developers.com/showthread.php?t=1363765
koush's + some extra wall papers + file explorer
all these things are just a completely alpha ics build with some hacks thrown in.. why?? why not just make a post in the ics thread (either by kwiboo or koush) saying "hey guys use launcher pro if you feel its buggy" or "here is link to glados kernel" instead of making "New ultimate sweet fast ICS rom" when all you are doing is downloading one of the actual source built ics roms and opening it with 7zip and dropping in a new boot.img in there then asking for donations :/
/rant
Click to expand...
Click to collapse
you missed these two.. http://goo.gl/bdy4w and http://fitsnugly.euroskank.com/sammich/crespo/
i can probably find you a few more if you would like more variety
simms22 said:
you missed these two.. http://goo.gl/bdy4w and http://fitsnugly.euroskank.com/sammich/crespo/
i can probably find you a few more if you would like more variety
Click to expand...
Click to collapse
lol im not mad that they are all buggy, im mad that people are "deving" with a buggy base and just adding to it. why not be a little patient, if you cant create it/build it from source, wait til the base you will be using to 7zip and copypaste into your rom becomes stable. dont use an alpha build to promote your name
icecoldbong said:
lol im not mad that they are all buggy, im mad that people are "deving" with a buggy base and just adding to it. why not be a little patient, if you cant create it/build it from source, wait til the base you will be using to 7zip and copypaste into your rom becomes stable. dont use an alpha build to promote your name
Click to expand...
Click to collapse
I don't think you quite understand how it works currently. There is no buggy base. They're attempting to adapt AOSP source code to compile and execute correctly on the Nexus S. This is way more complicated than you think. Almost all "bugs" you see are byproducts of tinkering with configurations, compile-ations, etc, in an attempt to get it working properly.
To put things in perspective, ICS development for the Nexus S is light years ahead of all other devices. For that reason alone, we should be grateful. Others are still struggling to either boot, or get somewhere AFTER boot.
If you don't like the way it's done, then wait for the official ROM. You have a choice, after all.
nickmv said:
I don't think you quite understand how it works currently. There is no buggy base. They're attempting to adapt AOSP source code to compile and execute correctly on the Nexus S. This is way more complicated than you think. Almost all "bugs" you see are byproducts of tinkering with configurations, compile-ations, etc, in an attempt to get it working properly.
If you don't like the way it's done, then wait for the official ROM. You have a choice, after all.
Click to expand...
Click to collapse
yes, two roms are getting built from the source on xda; kwiboo and koush. then all the others.
both kwiboo and koush thread is full of bug reports of people using a different rom like brainmaster, ultimate ics, kangorama ics, etc.
all this does is add confusion from the rom chef adding things to the original rom developers work
what im suggesting/ranting is that if a rom chefs should be a little more patient in making more spinoff roms that don't really add much besides to confusion for noob users
Your argument makes a LOT more sense now. I agree, if people are posting bugs in Koush/Kwiboo sections when running brainmaster or other tweaked versions, then that's bad.
Your original argument didn't really point this out.
Not much can be done about that, aside from aggressive moderation. Tweakers will be tweakers.
nickmv said:
Your argument makes a LOT more sense now. I agree, if people are posting bugs in Koush/Kwiboo sections when running brainmaster or other tweaked versions, then that's bad.
Your original argument didn't really point this out.
Not much can be done about that, aside from aggressive moderation. Tweakers will be tweakers.
Click to expand...
Click to collapse
Most of the bugs posted are not even valid. One in particular is known issue even on the GNexus.
The biggest issue I see is code optimization at this point.
One thing I think no one has mentioned is ICS may never be super fast on the NS. I will be much faster on dual core hardware
Bounced off a tower to a forum near you!
RonnieRuff said:
One thing I think no one has mentioned is ICS may never be super fast on the NS. I will be much faster on dual core hardware
Click to expand...
Click to collapse
This is one thing that has been bothering me as well. Every single one of these ROMs are not truly as smooth as Gingerbread. In no way do they even reach the fluidity found in Gingerbread ROMS. The hardware acceleration helps, but even then you can still feel the difference between the two Android releases. I have yet to hear a proper explanation as to why this is happening and I was hoping that the fix for this would be Google releasing the official Ice Cream Sandwich update.
Is it is code optimization as you say? Or is there more to it than that? I want to believe that hardware doesn't play a significant role here.
Eclair~ said:
This is one thing that has been bothering me as well. Every single one of these ROMs are not truly as smooth as Gingerbread. In no way do they even reach the fluidity found in Gingerbread ROMS. The hardware acceleration helps, but even then you can still feel the difference between the two Android releases. I have yet to hear a proper explanation as to why this is happening and I was hoping that the fix for this would be Google releasing the official Ice Cream Sandwich update.
Is it is code optimization as you say? Or is there more to it than that? I want to believe that hardware doesn't play a significant role here.
Click to expand...
Click to collapse
Agree 100% no released rom before ota is even out is worth running.. I ran koush or w/e and it worked but felt like I was holding a brick.. ruff! Brainmasters straight looks like android donut.. but so does cyanogens.. no disrespect to any of the above.. but htcclay is god..
Edit: wasn't brainmaster it was some one else.. sorry
Sent from my iPhone 4S using Siri
BLEEDCOLORYOU said:
Agree 100% no released rom before ota is even out is worth running.. I ran koush or w/e and it worked but felt like I was holding a brick.. ruff! Brainmasters straight looks like android donut.. but so does cyanogens.. no disrespect to any of the above.. but htcclay is god..
Edit: wasn't brainmaster it was some one else.. sorry
Sent from my iPhone 4S using Siri
Click to expand...
Click to collapse
Strange, I've found that Koush's latest (CM9 Alpha 11) is plenty fast, not significantly slower than GB. Definitely Kwiboo v2 was slow as molasses, but then again it came out days ago (a long time when it comes to how fast things are moving). BM v5 is pretty fast but buggy. Also, it seems that adding franco kernel to any of these also speeds things up significantly, but I haven't tried it with CM9 Alpha 11 yet.
oakamil said:
Strange, I've found that Koush's latest (CM9 Alpha 11) is plenty fast, not significantly slower than GB. Definitely Kwiboo v2 was slow as molasses, but then again it came out days ago (a long time when it comes to how fast things are moving). BM v5 is pretty fast but buggy. Also, it seems that adding franco kernel to any of these also speeds things up significantly, but I haven't tried it with CM9 Alpha 11 yet.
Click to expand...
Click to collapse
I found kwiboo's to be a lot more stable than koush's. although koush's had more functionality.. my bluetooth didnt work, and i got many errors.
Understand that we are using old binaries. ICS will run just as good as gingerbread, if not, better. These will make a world of difference
RonnieRuff said:
One thing I think no one has mentioned is ICS may never be super fast on the NS.
Click to expand...
Click to collapse
I'd kind of disagree with this. In its current early state here on the NS, I've gotten it running butter smooth and highly responsive, on a 1.1 OC/UV kernel. This is WITHOUT tweaks to filesystem, etc. If certain apps would just display properly when GPU Rendering is turned on, and some battery stuff worked out, I'd be 100% content.
Now granted, I've seen it running on the SGS2 and Galaxy Nexus and they're clearly speedier, but in my experience, my apps run just as fast as they did in GB.
On a side note....wanna see slow? It's been ported to the T-Mobile G1! HA! The first, original android phone!
I agree. there was actually a recent article on android police about this. There is no problem with people making their own roms but don't clog up the development section with "roms" that really all they do is bundle some easily downloadable market apps and some wallpapers and call it a new rom.
What the SGS2 xda forum actually did was split the dev section into 2 . One for original dev work and one for spin offs.

[DEV][WIP] CM9/Ice Cream Sandwich

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

Categories

Resources