Related
Good news guys!
Jerpelea announced the eminent release of Cyanogen RC2 for the X10.
http://forum.xda-developers.com/showpost.php?p=7370940&postcount=91
So to keep the dev only thread clean, please post your questions, problems or comments here.
Update 2010-07-28:
jerpelea said:
with actual state of spl it boots then crashes
you can play a lil with the new kernel included into package
build 0005
http://hotfile.com/dl/57983756/408a452/0005.rar.html
Click to expand...
Click to collapse
Great news and great work by the devs!
I think that this release will be internal i.e. devs only. We never got RC1 so why should we expect RC2?
you got that wrong guys
Froyo is ready in RC2 for X10 this is not equal to : "the bootloader is finally hacked"
So stay calm please
Regards
Bin4ry
Man i got excited for a minute there. Looks like back to waiting.
Sent from my X10i using the XDA mobile application powered by Tapatalk
Damn it!
Still good news that it'll be ready for when it does get hacked.
no more wet dreams.
ill stick it once it gets useful fr all...
its nice to see progress at least, I thought they hit a brick wall a couple days ago as they stopped posting in the dev thread. It may be a while till we see a bootloader hack thats friendly for us but its hard to determine since we're not devs. As I understand it, the actual ROM is partly ready but it'll have a number of bugs etc still and only devs who can actually load it on through manual code will be able to test it out I think. It may be that its actually just a virtual rom to be loaded onto the SDK under the same conditions as the x10 to be tested by the developers. I THINK. As I said I'm not a developer so take my words with a huge grain of salt because I might be completely wrong.
PLS Can we get a little more detailed information.
instigator008 said:
I think that this release will be internal i.e. devs only. We never got RC1 so why should we expect RC2?
Click to expand...
Click to collapse
PLS Can we get a little more detailed information.
If the RC2 will be ready tomorrow then it means that RC1 was launched on the device?
irkkso said:
PLS Can we get a little more detailed information.
If the RC2 will be ready tomorrow then it means that RC1 was launched on the device?
Click to expand...
Click to collapse
what is the meaning of rc1 and rc2
RC = Release Candidate
irkkso said:
PLS Can we get a little more detailed information.
If the RC2 will be ready tomorrow then it means that RC1 was launched on the device?
Click to expand...
Click to collapse
No no no... you got it all wrong.
RC2 is the latest release of CyanogenMod and work has been carried out on this to "Port" it over to the x10. There wasnt any point in working on RC1 if CM RC2 was out.
rc = release candidate
a software enters rc usually after testing phase(alpha-beta-etc...)....
j4mm3r said:
Good news guys!
Jerpelea announced the eminent release of Cyanogen RC2 for the X10.
http://forum.xda-developers.com/showpost.php?p=7370940&postcount=91
Click to expand...
Click to collapse
So Jerpelea made a edit on the post... which is something pretty much expected as the bootloader is not cracked. So my guess is that this is going to use the spl loader module to boot into the CM kernel which has been ported for X10? Just a guess...
Can somebody explain to people like me who are new on android what does the cyanogen mod, is it just a firmware ?
What is called "kernel" in android and is it "modable" and if yes, why would it be ?
The answers...
Vilam said:
Can somebody explain to people like me who are new on android what does the cyanogen mod, is it just a firmware ?
What is called "kernel" in android and is it "modable" and if yes, why would it be ?
Click to expand...
Click to collapse
Hi Vilam, those are interesting questions, let me see if I can address those to your satisfaction.
The term "firmware" being distinct from "software", in my view is rapidly loosing its ability to be distinguishable from the latter. Essentially it refers to those parts of the executable code on a computing machine which remains unmodifiable or rather "burned in" to the circuitry. With the advent of modern flash memory storage, which is rather malleable compared to the earlier variants which existed, it is rather easy to change and update the machine code which is stored therein.
In other words, you might still refer to firmware to be part of the "software" which runs on a computing device which is not modifiable at run-time. In terms of a smart phone (which are rapidly becoming general purpose computing devices anyways), the firmware forms the basis of the software execution environment which affords the so called "apps" to run and provide either ever so innovative and useful functions.
Coming around to the point about Cyanogen mod... its a combination of firmware and software (if you still want to make that distinction that is). It in conjunction with helper pieces of code like the bootloader et. all. can completely replace the components that your phone was originally shipped with. Since these are Android phones that we are talking about, Cyanogen is derived from the same code base that Google officially uses for their various releases of Android. It is important to note that Android is a mobile application and phone platform rather than something which can easily be classified as "firmware" or "software"
Next question of yours about the "kernel". Not knowing what your level of familiarity of Linux or its derivatives is... let just say that Android is essentially like a distribution (or distro) of Linux designed specifically to run on mobile devices. As is the case with other Linux distros, they are formed around a core known as the "kernel". The "kernel" forms the core of the operating system which provides a homogeneous execution environment for the execution of various applications, which are in-turn pieces of software which are designed to provide the functionality which can be useful to the end-user. So all the so-called "apps" require the kernel to provide some services which are abstracted out enough so that the application programmer does not need to care about the really really low level stuff that actually has to go down if you actually want your device to do something. Hence the application programmer concentrates on the "high level" stuff, which is the functions that are actually going to be useful to the end-user!!
Like all modern computing platform, Android is a layered architecture and the "kernel" forms one of the most inner most parts of it (hence the name "kernel").
The linux kernel running Android for the X10 is already modifiable. People have been successful in compiling software modules called "kernel modules" which can be added to a running kernel and add functionality to it (this of course requires super user privileges or "root" access on the phone).
With the future pointing towards the capability of running mods like Cyanogen and the likes, the possibilities of modding and hacking are endless. Cyanogen, like the original releases of Android from Google are completely open source, so one can tweak almost all aspects of the phone functions. The possibilities are only limited by ones own imagination.
PS: I think I had too much beer and it makes me practice my English composition skills... hic!
Thank you very much for this clear explaination !
Please let me explain in newbie wordings. This is for ppl who can't understand what's going on at all.
1. A firmware likes an OS, if not exactly is. Windows, Linux, DOS, OS X are all OS. In android phone, there is merely one OS, which is Android.
2. Android is Linux.
3. Linux has a kernel, which is the main program. Without this, your machine can't run. On top of kernel, there is other software (movie player/web browser). Kernel + other software = distro (distribution).
4. Windows has different distro like Home, Professional, Ultimate... Linux has also different distro, so does android. One of them is CyanogenMod. The other could be Xperia X10 original.
5. Android is open source, so everyone can mod it. But that does also means someone can remove functions from it, one of them is Sony Ericsson, which locks your Xperia X10 for professional use.
6. While it is easy for us to upgrade Windows XP to Windows 7. It is difficult to install OS X from Windows XP. This is the same case for Android, it is easy to upgrade our Xperia X10, but it is not that easy to install CyanogenMod. There are honorable person working on this issue.
7. Why CyanogenMod? Because it is faster or it does not lock function like original Sony distro.
8. Just like installing OS X on regular PC, installing CyanogenMod may brick your machine. Much worse, Sony will definitely don't get your X10 repaired. So think if you need that extra function.
Can someone kindly explain why porting the Nexus S to the Vibrant doesn't work? I have tried to use "Search" but have been unsuccessful with finding in depth information on the subject. From what I have gathered, with the exception of Bluetooth 2.0 vs. 3.0, Front Facing Camera (VGA) lack of external storage, and obviously Android 2.3. There is no other difference. I guess I'm wanting a more technical answer regarding the differences. Yes I understand regarding modems/source codes etc. But I still don't get it. I'm more of an amateur over-clocker on desktops and I guess the differences vs. a desktop and smartphone are greater than I initially realized. Perhaps my chosen search definitions aren't specific enough or are too vague. I'm sure this may have been beaten to death but my want to know has gotten the better of me. I find this community to be full of knowledge but I fear that using search can be frustrating. Thanks in advance for you expertise guys (gals) BTW the similar threads box is awesome.
because porting doesn't involve copying the nexus' rom and pasting it on the vibrant.
the Drivers, which run the whole phone are incompatible, there is a ALPHA build version, with no gps, the buttons are switched, voice doesn't work, etc.
Drivers are not possible for devs to make, and only samsung, and other manufacturers, can make them, and make it compatible.
xriderx66 said:
because porting doesn't involve copying the nexus' rom and pasting it on the vibrant.
the Drivers, which run the whole phone are incompatible, there is a ALPHA build version, with no gps, the buttons are switched, voice doesn't work, etc.
Drivers are not possible for devs to make, and only samsung, and other manufacturers, can make them, and make it compatible.
Click to expand...
Click to collapse
Thanks for your response. I do understand that "cutting & pasting" is a no go. But what got me curious is that the hardware is the same. So speaking from a PC Geek's view a series of GPU's if you will can be produced by different third party vender's. However the Drivers would be the same even if the third party vender changes the BIOS they could still be flashed to another card ex. flashing ASUS bios to a similar card like a MSI GPU. Some vender's may slightly change the user interaction ex. software suites for "tweaking" settings ie over-clocking. So I guess this is why I'm asking what is so different regarding these two phones that prevents a "clean" port. If the hardware was a completely different generation I totally could understand. This unless I am wrong (which I probably am) is what is bending my logic.
Edit: I stand corrected the Nexus is different
http://www.ifixit.com/Teardown/Nexus-S-Teardown/4365/1
vs.
http://www.ubmtechinsights.com/repo...stigative-analysis/samsung-galaxy-s/teardown/
amwilliams9 said:
Can someone kindly explain why porting the Nexus S to the Vibrant doesn't work? I have tried to use "Search" but have been unsuccessful with finding in depth information on the subject. From what I have gathered, with the exception of Bluetooth 2.0 vs. 3.0, Front Facing Camera (VGA) lack of external storage, and obviously Android 2.3. There is no other difference. I guess I'm wanting a more technical answer regarding the differences. Yes I understand regarding modems/source codes etc. But I still don't get it. I'm more of an amateur over-clocker on desktops and I guess the differences vs. a desktop and smartphone are greater than I initially realized. Perhaps my chosen search definitions aren't specific enough or are too vague. I'm sure this may have been beaten to death but my want to know has gotten the better of me. I find this community to be full of knowledge but I fear that using search can be frustrating. Thanks in advance for you expertise guys (gals) BTW the similar threads box is awesome.
Click to expand...
Click to collapse
difgerent radio, difgerent storage inand on ns, basically two different phones
And most importantly the lack of vibrant source code
Sent from my Nero powered Vibrant
Guys (and girls ... if any are reading .. )
After some tinkering about (for days now) with Mango build 7720 (Thanks again YUKI + XBOXMOD!) I can confirm that the many of the issues present in Mango Beta are now gone ... Ok granted the MicroSD gets encrypted but its not meant to be removed on an original WP7! You can refer to Yuki's thread on how to unlock your MicroSD card if you don't fancy the likes Microsofts OS and want to revert back to Android .....
Now, it's a known fact that multitouch is an issue together with sound and camera. I was unable to find solutions to this issue. This thread seeks to ask / reply and hopefully implement some of the issues which remain for us to make the HD2 and hopefully run Android and WP7 natively without the abstraction layer present in the secondary bootloaders.
Question 1 - I am aware that CLK runs android only. Are the sound / camera / and multitouch issues present in WP7 also present in Android NAND roms running on CLK ?
Question 2 - How possible is it to modify CLK to run WP7 if the answer to above is NO?
Question 3 - If the issue iies in the secondary bootloader drivers (if any) ... Is there a way to modify/contribute for further development on them?
If we resolve these the HD2 would truly be a remarkable piece of hardware running virtually any OS. Presently the multitouch issue kills some of the enjoyment on WP7 ... and the source sound input gain is too high.
I really wish if we could get some serious thread going and if anyone is confident that he/she can help resolving the driver issue, feel free to pm me. I am a software developer (c#) if this can help in any way. Have been using it some years now on a daily basis. I am willing to provide my help. I hope that anyone could help along maybe we create yet another open source bootloader which does the trick.
Hoping to hear from you so we get something going ...
Regards
Al
I would really like to hear from some devs I am more than sure that the community would be very grateful.
Secondly (courtesy of warriorvibhu)
I suggest that you all Sign this Petition.. Kindly inform all fellow HD2 owners to sign it ... especially if they were impressed by WP7 on HD2.
Alcatrazx said:
Guys (and girls ... if any are reading .. )
Now, it's a known fact that multitouch is an issue together with sound and camera. I was unable to find solutions to this issue. This thread seeks to ask / reply and hopefully implement some of the issues which remain for us to make the HD2 and hopefully run Android and WP7 natively without the abstraction layer present in the secondary bootloaders.
Question 1 - I am aware that CLK runs android only. Are the sound / camera / and multitouch issues present in WP7 also present in Android NAND roms running on CLK ?
No there are some issues in camera and sound with android but is related to incomplete kernel. They are not related to each other for example no multi touch issues on android. All those issues are related to not perfect drivers hd7 is using another touchscreen panel I guess and maybe different speakers and camera. Anyway those drivers are complexed to write because we dont get source from microsoft on how to write them.
Question 2 - How possible is it to modify CLK to run WP7 if the answer to above is NO?
Theoritically yes but CLK is designed to load an linux kernel. So if we want that we need to write a complete new bootloader.
Question 3 - If the issue iies in the secondary bootloader drivers (if any) ... Is there a way to modify/contribute for further development on them?
Yes but you need to go backt to Windows 6.5 and read out the current drivers and port them to windows phone 7 properly. But you will need a JTAG for it and you must be very skilled.
If we resolve these the HD2 would truly be a remarkable piece of hardware running virtually any OS. Presently the multitouch issue kills some of the enjoyment on WP7 ... and the source sound input gain is too high.
I really wish if we could get some serious thread going and if anyone is confident that he/she can help resolving the driver issue, feel free to pm me. I am a software developer (c#) if this can help in any way.
Hoping to hear from you so we get something going ...
Regards
Al
Question
Click to expand...
Click to collapse
Hope this make some stuff clear.
You talk about a sound issue.
If your talking about the sound being too high, then a cab can be downloadeed to fix this. Doesnt limit the maximum volume, just reduces the minimum and puts bigger steps in placce.
We need an asm developer for try to fix multitouch problem... or the source code of driver...
Multi-touch is a bit better for me (don't know if the games which need two screen pressure work I didn't tried yet) but in Bing Maps and IE9 it's working most of the time.
Just hope that's will come soon, I cant wait it !
However, I also hope the Mango will worked with flash and include more apps in the marketplace.
Fisher_9511 said:
Multi-touch is a bit better for me (don't know if the games which need two screen pressure work I didn't tried yet) but in Bing Maps and IE9 it's working most of the time.
Click to expand...
Click to collapse
Its not working in any of multitouch Games.
Nice thread,curious to See the answers, definitely camera is a big issue for me, hope it get fixed soon.
Sent from my HTC HD2 using XDA App
Dont forget the need to use the "batterytrick"
good thread by the way
Unfortunately the thread won't lead to anywhere. Development on WP7/7.5 is not like development on Android. WP7 is closed source and so is the drivers.
So unless HTC themselves step in or a developer hacks new drivers up(which won't happen). We'll never see a native WP7.
We're using all the stuff that was leaked from the original LEO ROM. Also, CLK with WP7/7.5 boot support would not change this. And no, all these problems are not present in Android. But that's because the developers have more tools and open source code to work with, something we don't have.
Try to think positive man... Have you ever seen the arm listed file? We need to find a timer between the two finger... would not be so so so hard... but only hard...XD
TonyCubed said:
Unfortunately the thread won't lead to anywhere. Development on WP7/7.5 is not like development on Android. WP7 is closed source and so is the drivers.
So unless HTC themselves step in or a developer hacks new drivers up(which won't happen). We'll never see a native WP7.
We're using all the stuff that was leaked from the original LEO ROM. Also, CLK with WP7/7.5 boot support would not change this. And no, all these problems are not present in Android. But that's because the developers have more tools and open source code to work with, something we don't have.
Click to expand...
Click to collapse
Hi and thanks for the feedback. With a negative attitude the thread will lead to nowhere yes. That was what people said a year ago when they said that WP7 will never run on the HD2 but the devs ultimately got there. Thanks for answering the question re the Android drivers though.
You are RIGHT that the drivers in WP7 are closed source drivers ... so is MAGLDR. Rewriting another bootloader (if needed) which does not have all the frills of MAGLDR but which is open source could be a possibility.
I am not interested in getting into the WP7 ROM and modifying the drivers built in ... We have to use a technique similar to what they use when creating emulators by reverse engineering ... The most die hard emulators out there such as some of the Playstation emus out there were all closed source but it did not stop the devs from doing a proper emulation of the console.
I'd really appreciate if you could be more specific when you said that we are using the stuff which was leaked from the original "LEO" ROM ... as far as I know, is it not the Schubert which was leaked? Correct me if I'm wrong ... We got too far to give up just now...
Multitouch games do not work .. with the current Multitouch driver .. mainly due to the finger position bug .... This is explained in detail on youtube.
Sound is distorted because the input gain is too high ...
Let's not speak about the camera for now ... I think those are the two major issues which need to be remedied for now. Hopefully this thread will get us somewhere.
Regards
Al
Good initiative ! I hope we can make things work.
Also for those with the negative attitude...if you dont have anything good to say...dont say !
backlashsid said:
Good initiative ! I hope we can make things work.
Also for those with the negative attitude...if you dont have anything good to say...dont say !
Click to expand...
Click to collapse
Nicely said and many thanks
You talk about a sound issue.
If your talking about the sound being too high, then a cab can be downloadeed to fix this. Doesnt limit the maximum volume, just reduces the minimum and puts bigger steps in placce.
Click to expand...
Click to collapse
That is not exactly fixing the issue... It just modifies the maxima and minima ... The sound (input gain) is too high making it sound distorted from the HD2. The fix does remedy this a bit but its ... erm not really fixing the problem.
do think this would be a good idea, but its not being negative pointing out the obvious issue, its being realistic.
you see the point you made on MAGLDR and WP7 running of the HD2 is mute, and im not sure you fully understand its use, there are fundamental differences in making WP7 believe the HD2 is a native device and changing the actual drivers, you see, the SPL for the HD2 was opened up a long time ago with HSPL to be put in place which pretty much allowed us to do anything, the next critical piece was MAGLDR, which sat on top of the HSPL which gave us the potential to install android then WP, both HSPL and MAGLDR are very much programed by folk on here, they were not "hacked" or copied, they are closed source as you put it but they are built for a purpose of doing exactly what they do, enable custom ROMs, for WM, Android and WP to install. But that’s not the issue, the issue is a driver
To be clearer on the matter, IF WP7 had never been tested on the HD2 initially then we would never have had it.
The reasons for the bugs we talk about are because we have test drivers that were never supposed to see the end user. Had we not had that opportunity with the drivers on the HD2 then we would have been up the creek with it.
There are only a number of possibilities to get what we want
•HTC/OEMs go out of their way to finish the HD2 WP7 drivers and give them to use
•HTC/OEMs gives us the Relevant code and tools to do it ourselves
•We find native Windows phone devices that uses EXACTLY the same hardware which we can borrow
•Finally, the wildcard, someone who happens to know how to program for the hardware in question comes to help us.
That is it im afraid, its not being negative, you want to know what we need to do, well, there you go, the chances of HTC etc helping us are almost non-existent, finding devices with the same hardware, well i think we have more of a chance of HTC giving us them, BUT thats more to do with the very old digitiser we have, less so with the other hardware elements, so there is a possibility there.
Finding someone who can actually build a driver from the ground up? its possible, but short of putting adverts out on every developer website asking for help its not likely we will find one from this thread alone.
dazza9075 said:
do think this would be a good idea, but its not being negative pointing out the obvious issue, its being realistic.
you see the point you made on MAGLDR and WP7 running of the HD2 is mute, and im not sure you fully understand its use, there are fundamental differences in making WP7 believe the HD2 is a native device and changing the actual drivers, you see, the SPL for the HD2 was opened up a long time ago with HSPL to be put in place which pretty much allowed us to do anything, the next critical piece was MAGLDR, which sat on top of the HSPL which gave us the potential to install android then WP, both HSPL and MAGLDR are very much programed by folk on here, they were not "hacked" or copied, they are closed source as you put it but they are built for a purpose of doing exactly what they do, enable custom ROMs, for WM, Android and WP to install. But that’s not the issue, the issue is a driver
To be clearer on the matter, IF WP7 had never been tested on the HD2 initially then we would never have had it.
The reasons for the bugs we talk about are because we have test drivers that were never supposed to see the end user. Had we not had that opportunity with the drivers on the HD2 then we would have been up the creek with it.
There are only a number of possibilities to get what we want
•HTC/OEMs go out of their way to finish the HD2 WP7 drivers and give them to use
•HTC/OEMs gives us the Relevant code and tools to do it ourselves
•We find native Windows phone devices that uses EXACTLY the same hardware which we can borrow
•Finally, the wildcard, someone who happens to know how to program for the hardware in question comes to help us.
That is it im afraid, its not being negative, you want to know what we need to do, well, there you go, the chances of HTC etc helping us are almost non-existent, finding devices with the same hardware, well i think we have more of a chance of HTC giving us them, BUT thats more to do with the very old digitiser we have, less so with the other hardware elements, so there is a possibility there.
Finding someone who can actually build a driver from the ground up? its possible, but short of putting adverts out on every developer website asking for help its not likely we will find one from this thread alone.
Click to expand...
Click to collapse
ur right...man sometimes i so feel like bombarding Drew Bamford (product design HTC) emails about windows phone 7 and androi on HD2 and force him to be convinced to make drivers for us....its our right
but then again...can we really ???
backlashsid said:
ur right...man sometimes i so feel like bombarding Drew Bamford (product design HTC) emails about windows phone 7 and androi on HD2 and force him to be convinced to make drivers for us....its our right
but then again...can we really ???
Click to expand...
Click to collapse
I'd say... let's do this! If we get enough people, and those will send emails like everyday, then why not? There's nothing to lose
IF, and its a big IF, we are going to get it working better its going to need ideas like the comment from backlashsid to get unofficial support from these companies
In my humble opinion there is little chance of getting anything else working better without the support of people in the loop, essentially that means HTC and Qualcomm, but remember that by getting the HD2 running WP7 we are costing them money in lost sales, so there is little incentive for them to support us in an official capacity, what we're looking for is an insider!
it doesnt hurt hunting for new devices with the same hardware but its unlikely anyone would use old gear.
This would be nice so then we (as the community of XDA) can show off our HD2's as the beast-mode phone and bestest phone ever!
Hi guys
I'm aware of CyanogenMod, but is it possible to have a completely stock JB ROM with no mods (other than busybox, deodexing, etc..) or custom apps installed? I can't seem to find one
Cheers
The community will correct me if I'm wrong, but I believe you'd have to build from source (AOSP) if you wanted something that is super-vanilla and hasn't been touched by a manufacturer outside of CM, AOKP, etc.
That said I also believe this particular question should be posted in the General or Q&A sections, for future reference.
djmatt604 said:
The community will correct me if I'm wrong, but I believe you'd have to build from source (AOSP) if you wanted something that is super-vanilla and hasn't been touched by a manufacturer outside of CM, AOKP, etc.
That said I also believe this particular question should be posted in the General or Q&A sections, for future reference.
Click to expand...
Click to collapse
Thanks for the reply
I mean Android was made to work on all devices right, but does CM do something like adding "drivers" (or the equivelent)? Is that what developers do when they "port" something like a new ROM that has been released on a similar device?
If multiple devices have a stock Android JB ROM, and they're also using a Tegra 2 CPU (and I'm guessing they all use the same type of RAM) etc.. is it quite easy to port? Do you have any idea how difficult it would be to compile it from source/getting it to run on a device?
I'm into technology, but without some serious research, I wouldn't have a clue where to start unfortunately
P.S. Yeah I realised after, already reported it to be moved
I've never ported between devices, but I've read enough to say confidently that things can be tough if you are porting between devices that are too different. At the very least you should stick between manufacturers...like it would be easier to port from Galaxy S2 Hercules to S2 Skyrocket for example than it would be from S2 to HTC xxx. There are quite a few good guides that explain how to port safely as long as the board configs and other important stuff are the same. If you aren't sure, don't do it.
For compiling from source, do a search on XDA here for shenye's guide "Compile JB on Ubuntu" - it was also featured on XDA TV. It's very helpful. Compiling isn't all that hard, but takes time and patience especially if you are working on a non-flagship device. It will likely take much research to find the right repositories for your device and vendor config, plus time to fix any errors the compiler reports.
Good luck!!
Hi there,
I'm a programmer and formerly worked for one of the major Android handset developers as a platform engineer. When we developed the devices, we had separate build configurations and tools for kernel and platform, and built them separately... I rarely had any issue in building a new kernel for a platform, or building a new platform and using it with an old kernel.
That being said, what is the present difficulty that is being run into with using what should be a fully-functional GB kernel (incl. graphics drivers) with the ICS or JB platform? I am genuinely curious on this mark - if you are using the original kernel and drivers, I would imagine you should have full functionality (as they expose at least OpenGL ES in a consistent manner).
If you reply, please don't water down your comments - I'm a kernel developer myself (though not for Linux), so I appreciate and look forward to technical jargon.
"GPU Acceleration" (Hardware Acceleration) I'd imagine would be handled via the OpenGL interface libraries that come with the driver... that's what I'm asking: why can't the Gingerbread ones be used? What specifically prevents it from working? What's preventing you from modifying the ICS/GB platform to be compatible with "less-featureful" drivers?
As I said, I used to do this professionally, and am a professional programmer, so I'm looking for specifics.
AmeiseMike said:
What's preventing you from modifying the ICS/GB platform to be compatible with "less-featureful" drivers?
Click to expand...
Click to collapse
Nothing. And that's exactly what the devs have been doing so far. The result is well known to everyone - an almost perfect system that's lacking true HW acceleration in certain areas. Modifying and adapting can only get you so far.
I'm no expert so I won't pretend to be one, but as far as I know it has something to do with the newer nvidia drivers (that support proper HWA) which are proprietary binary blobs and have only been released for kernels newer than what we have. So we have a working kernel with semi-working adapted drivers, or true proper drivers with no kernel to use them on. And that's exactly where all the current porting efforts are directed - making a working kernel for the Atrix that's recent enough to make video drivers useful. In fact, since you say you have quite some experience with kernel development, you might consider joining the team, I'm sure they can always use any help they can get.
You could theoretically use existing drivers from kernel space, but they are not compatible with ICS.
Another option would be to ask nVidia nicely for drivers then build a new kernel, not forgetting two dozen other neccessary drivers, too.
OR, you could use a newer kernel with drivers that are compatible with ICS and which includes better handling of resources.
Option one will be adequate for Honeycomb. Hardware acceleration was first introduced in API level 11 (Honeycomb) and the XOOM was horribly buggy and slow with the old kernel.
Option two will never happen for various (obvious) reasons. For hardware acceleration to work properly you need nVidia drivers which require a 3.0 kernel.
Option 3 is something that a few in the Atrix community are working on.
My question, though, is why are said drivers incompatible with ICS/JB? What has changed that has rendered the platform incompatible with the previous drivers? If 3d Hardware Acceleration worked in GB, why can it not be used within ICS/JB (which should only care about GL ES, which hasn't changed)? If a feature of some sort has been added in ICS/JB that has caused the incompatibility, why not disable it? Features that had worked shouldn't be rendered inoperable unless a binary-level incompatibility exists, and I can't fathom why one would when you have platform source (via AOSP).
That is a question i'm afraid no one other than nVidia can answer. Why do their HA drivers require a 3.0 kernel is the question to ask.
---------- Post added at 10:37 PM ---------- Previous post was at 10:34 PM ----------
What existing HA in GB are you referring to?
integraletotale said:
That is a question i'm afraid no one other than nVidia can answer. Why do their HA drivers require a 3.0 kernel is the question to ask.
---------- Post added at 10:37 PM ---------- Previous post was at 10:34 PM ----------
What existing HA in GB are you referring to?
Click to expand...
Click to collapse
OpenGL ES 1 and 2 fully function on Gingerbread (and are accelerated, that is, not rasterized by something like Mesa). These are components of the GPU driver, more specifically the GLES interface libraries. I don't see why those are rendered incompatible.
That stretches beyond my knowledge of what is made available by the driver, so, I really don't know. I'd greatly appreciate you taking a minute to review progress being made on github. Links in the development section of this forum in the thread mentioned earlier.
To put it into a different context (approaching it a different way), have any other OSen such as Ubuntu been ported to the Atrix, using the kernel, and having 3d HWA?
Not sure if it's useful information or..... but from what I've read even the GB kernel used by Motorola for the Atrix was just a cobbled up rush job based on a Froyo kernel..
So the ROM developers here have a steeper hill to climb than you thought.... Making ICS/JB ROM's operational from basically a patched Froyo kernel
I once got Honeycomb working on a Froyo device (don't ask), including HWA... without any kernel changes.
My suspicion is that maybe people are unwilling to hack up the platform to work with the drivers as they are? So long as there are drivers that have supported HWA, there's no reason that they shouldn't be able to continue to do so, you have to alter the platform so that it can. ICS/JB internally will look a bit more like GB afterwards, but many of ICS/JB's improvements were in the realm of expanding what used HWA (which already existed) and improvements in their multithreading code, neither of which should require anything that's not already there.
EDIT: I'd point out that I'm speaking hypothetically. I don't know what the actual issue is, hence why I'm probing for specifics .
Are there any developers around who might be able to shed light upon this for me?
Hi,
What eaxctly do you need this information for? Are you working on porting Ubuntu Touch on the Atrix?
AmeiseMike said:
Are there any developers around who might be able to shed light upon this for me?
Click to expand...
Click to collapse
here's a link http://forum.xda-developers.com/showthread.php?t=2016837 , maybe you'll get your answer there
I'm not sure what that link has to do with my original question? I'm aware that attempts for porting other kernels are being undertaken, what I am wondering is why it's necessary (and not a vague 'because x and Y require a new kernel, but specifics).
AmeiseMike said:
I'm not sure what that link has to do with my original question? I'm aware that attempts for porting other kernels are being undertaken, what I am wondering is why it's necessary (and not a vague 'because x and Y require a new kernel, but specifics).
Click to expand...
Click to collapse
You asked are there any developers around who might 'shed some light' on your question. There's only a handful of developers left and the link takes you to some of the most current ones. You can also check out the others in the Development section.
What exactly do you need this information for?
To see if there's an alternate route towards porting newer versions of the platform to the phone (as I said, I've ported platforms to older kernels before when I was employed by one of the manufacturers), and as a hobbyist forking Android and porting it to my phone (which is an Atrix).
I'm just very confused as to what the problem is that necessitates a new kernel; I didn't have any issues like this when porting platforms before - I merely altered the platform so that it would work with the older drivers (sometimes that required disabling newer functionality, but functionality that worked beforehand was still there).
AmeiseMike said:
To see if there's an alternate route towards porting newer versions of the platform to the phone (as I said, I've ported platforms to older kernels before when I was employed by one of the manufacturers), and as a hobbyist forking Android and porting it to my phone (which is an Atrix).
I'm just very confused as to what the problem is that necessitates a new kernel; I didn't have any issues like this when porting platforms before - I merely altered the platform so that it would work with the older drivers (sometimes that required disabling newer functionality, but functionality that worked beforehand was still there).
Click to expand...
Click to collapse
Instead of asking, why not try and do it and see for yourself.:good:
Because I'm not interested in potentially bricking / rendering unusable my phone if there's a known good reason why it can't be done.