Related
some devs say stop complaining about a2dp. its not working and blame tegra. Well my take is that the great minds on this site are capable of doing anything they put their minds to. just look at the hd2 forums. this is a windows mobile phone running almost every os out there. isn't the purpose of the customs roms to bring out the best features and true power of our phones. If that the purpose then isn't a2dp a great feature to have. it completely allows us to cordless from our phones. I'm sure many would reward those responsible for making this happen, just like with the lg cam on gingerbread.
thanks you all for the great and tireless work you do to make our phones as customizable as we want.
I'm not a dev, but building a driver for something like that is a lot more labor intensive than re-engineering an existing camera app. You're talking weeks of work. A2dp works with the stock-based ROMs on the G2x just fine--I used it just about every day.
I know that they work with them. I'm sure it would take some time. Like I said just look at the hd2 for proof of what can be done. They said it couldn't be done and cotulla and others made it possible. I'm not sure but I would think then maybe it would work for all android phones.
They still don't have the lgcam working on cm7 and that was the main purpose. So it must not be as simple as u make of sound.
Sent from my LG-P999 using XDA Premium App
Well, it's always so nice to see someone be so charitable with other people's time.
i would be glad to contribute some of my hard earned money. for this time u say im being generous with.
Well, you have to realize the hd2 was a whole other beast. What cotulla did was write the radio inside magldr to mimic the desire. (The reason he never opened up the source code was because of this fact, it was the only way to get rmnet working instead of ppp. Opening the source code would've allowed for people to hack the radio on it, which is not good. He did the responsible thing keeping it closed imho.) Infact, most of the drivers were ported based on the source code for the desire. (They were similar enough in hardware to where that was a good base to work with.) I used that phone for quite a while, and if you remember, a2dp wasn't working on there (hell, NO bluetooth what so ever) until they released the source code for the desire. Once that happened, it was easy to port things over.
Look, if aremcee can't get it working, with his ridiculous know-how, it's not going to happen without the source code being released (or at the very least, newer drivers.) Also, the hd2 doesn't have the same radio configuration as the g2x. The hd2 had documentation on it, it was a qualcomm radio. This one, nvidia, isn't documented. (And anyone who uses linux will agree, nvidia can be rather stingy about releasing source code.)
Another thing to remember, it took cotulla and his team a good year plus to reverse engineer the drivers just to get it loaded off nand. (And I frequented the irc a lot that they were on, it was far from easy.) And before nand, it was loaded with haret.exe (Handheld reverse engineering tool.) What this did was shutdown windows mobile, but keep certain things in memory intact to piggyback on to load the radio and other things. Once again, it was done with other things running, not written from scratch. If memory serves (and unless it's been fixed, haven't checked in a while,) cLK is the alternative to magldr, and it still doesn't have working rmnet, it's ppp only. It will probably never have working rmnet.
And please, this is not to take anything away from the amazing work the devs do here, they are truly talented, I'm just trying to explain this because of the massive amount of misinformation that gets spread so quickly.
Thanks for taking your time to write that. That really finally explains it clearly. You do get a lot miss information around here.
Sent from my G2x using XDA Premium App
[NOTE]: Mods please move this thread to general Q&A if you find suitable, posting here because I think question comes more towards development side.
So now the question is:
Here are things which I know (mostly read somewhere / heard from friends etc.)
I'm seeing CM7 progress and time to time devs saying can't go ahead because Wimax driver / GPS driver is proprietary (what exactly does it mean?). While as I was discussing with friends I came to know Android only provide HAL so by logic all drivers should be proprietary or no?
I'm quite sure I've not understood something properly so I wanted to know
1. are drivers available only by manufacturer and Android only provide HAL?
2. If yes then what would it take to fetch those drivers and try writing HAL?
3. If no then how can one start writing own drivers?
I know its not an easy process at all, but I was curious so asking here.
I would appreciate all inputs, and if anyone want to share links I am up for some reading
Thanks
wis3m0nkey said:
So now the question is:
I'm seeing CM7 progress and time to time devs saying can't go ahead because Wimax driver / GPS driver is proprietary (what exactly does it mean?). While as I was discussing with friends I came to know Android only provide HAL so by logic all drivers should be proprietary or no?
I'm quite sure I've not understood something properly so I wanted to know
1. are drivers available only by manufacturer and Android only provide HAL?
2. If yes then what would it take to fetch those drivers and try writing HAL?
3. If no then how can one start writing own drivers?
Click to expand...
Click to collapse
Android does not provide a "HAL" as in the Windows (NT) sense. Android is an operating environment running on the Linux kernel, and the programs (apps) running in Dalvik (Java-based).
The issue with CM/other generic AOSP-based build is twofold. First the driver to interface with the underlying has to be compiled into the Linux kernel. Luckily for most of us, the majority of smartphones are based on a few common chipsets (Qualcomm MSM etc.), so chances are you can find the source for a similar phone, and try to fiddle with the source to make it work. This also means that esoteric hardware (ie. WiMax) has a lot harder time getting the driver working.
Second is what allows the Android apps to use the driver to communicate with the hardware. This is where the issues like GPSone rears its ugly head, as it seems each manufacturer likes to do it's own way, so unless you are basing things on the mfg's Android builds, it's almost impossible to get it to "talk" to the driver.
In the end, that's why builds based on official/leaked builds have a lot easier time gettin everthing working because both kernel and userland "bits" are there.
-- Starfox
Starfox said:
Android does not provide a "HAL" as in the Windows (NT) sense. Android is an operating environment running on the Linux kernel, and the programs (apps) running in Dalvik (Java-based).
The issue with CM/other generic AOSP-based build is twofold. First the driver to interface with the underlying has to be compiled into the Linux kernel. Luckily for most of us, the majority of smartphones are based on a few common chipsets (Qualcomm MSM etc.), so chances are you can find the source for a similar phone, and try to fiddle with the source to make it work. This also means that esoteric hardware (ie. WiMax) has a lot harder time getting the driver working.
Second is what allows the Android apps to use the driver to communicate with the hardware. This is where the issues like GPSone rears its ugly head, as it seems each manufacturer likes to do it's own way, so unless you are basing things on the mfg's Android builds, it's almost impossible to get it to "talk" to the driver.
In the end, that's why builds based on official/leaked builds have a lot easier time gettin everthing working because both kernel and userland "bits" are there.
-- Starfox
Click to expand...
Click to collapse
Ok so if I understood this properly :
Driver (which resides in kernel) services can be accessed by Dalvik.
And apps access services provided by Dalvik.
So in this case drivers for android would be developed in same fashion as for any other linux based system. Only requirement would be to check for manufacturer data sheet (if not source code) to tamper with.
Am I correct?
And is there a general development thread specifically for epic 4g?
Thanks
wis3m0nkey said:
Ok so if I understood this properly :
Driver (which resides in kernel) services can be accessed by Dalvik.
And apps access services provided by Dalvik.
So in this case drivers for android would be developed in same fashion as for any other linux based system. Only requirement would be to check for manufacturer data sheet (if not source code) to tamper with.
Am I correct?
And is there a general development thread specifically for epic 4g?
Thanks
Click to expand...
Click to collapse
The difficulty is that manufacturers don't seem to release data sheets for proprietary (customized by the manufacturer) hardware...
Sent from my SPH-D700 using XDA App
styles420 said:
The difficulty is that manufacturers don't seem to release data sheets for proprietary (customized by the manufacturer) hardware...
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
Aww man isn't it bad? I mean its same as what Apple tried doing with architecture specific Macs even Windows is trying with secure boot :-/ (But this is with phones compared to computers)
Why can't they just let devs work? I understand them having proprietary drivers but they should provide all required data to write one as well..
Well anyways I figure it won't matter even complaining about it. Anyways thanks guys I'll see if I can find any more info on manufacturer specific code.
wis3m0nkey said:
Aww man isn't it bad? I mean its same as what Apple tried doing with architecture specific Macs even Windows is trying with secure boot :-/ (But this is with phones compared to computers)
Why can't they just let devs work? I understand them having proprietary drivers but they should provide all required data to write one as well..
Well anyways I figure it won't matter even complaining about it. Anyways thanks guys I'll see if I can find any more info on manufacturer specific code.
Click to expand...
Click to collapse
This isn't a Mac vs PC thing.
This is a chip thing. Providing full disclosure of the register set makes some manufacturers nervous. Primarily because with some components, enough information needs to be provided such that you could potentially copy the device. Or at least features of it.
Qualcomm and Broadcom are very bad at this. They don't release anything unless it's under at least 5 NDAs.
I think u misunderstood me. I didn't say about mac vs pc. I was trying to give example about secure boot and macs rejecting to support all hardware.
Yes I understand chips can be duplicated but if its manufactured by samsung only then they shouldn't have problem
wis3m0nkey said:
I think u misunderstood me. I didn't say about mac vs pc. I was trying to give example about secure boot and macs rejecting to support all hardware.
Yes I understand chips can be duplicated but if its manufactured by samsung only then they shouldn't have problem
Click to expand...
Click to collapse
If it gets duplicated, it is no longer manufactured by Samsung only, and therefore is a problem.
Sent from my SPH-D700 using XDA App
seeing as android is a linux based operating system i dont understand why it wouldnt be possible to actually simply build the drivers from scratch. Ive done things like this for Wificards for my debian laptop as well as video drivers for intel chips that dont have linux based drivers. if they work the same way as the linux kernel does wouldn't it be logical to be able to do something similar?
metalblaster said:
seeing as android is a linux based operating system i dont understand why it wouldnt be possible to actually simply build the drivers from scratch. Ive done things like this for Wificards for my debian laptop as well as video drivers for intel chips that dont have linux based drivers. if they work the same way as the linux kernel does wouldn't it be logical to be able to do something similar?
Click to expand...
Click to collapse
It's the chip that is proprietary - those wifi cards use relatively well-documented chip sets, our phones do not. Unless you're aware of another device that uses the -exact- same chipset, with driver source code? (The question is rhetorical)
Feel free to guess at the unique opcodes and such, but trial and error will take a really long time
Sent from my SPH-D700 using XDA App
I'm glad to see some answers on this topic as I was curious about it as well. Can anyone comment on how past drivers have been hacked? E.g. how the Evo got Wimax working in cyanogen? Did they just trial and error the hell out of it until everything worked or did someone get inside information?
Some info
I'm pretty sure devs already have looked at it however anyone else who is wondering:
http://www.chipworks.com/en/technic.../teardown-of-the-samsung-epic-4g-smart-phone/
Samsung CMC730S WiMax baseband processor with SDRAM
That is wimax chip for epic 4g. I couldn't find more info that the chip itself, will report again if I come close to anything
So apparently Samsung SWC-E100 XOHM ExpressCard also uses same Wimax chip.
I'm checking if there are linux drivers available for the card.
http://www.wireless-driver.com/samsung-swc-e100-wimax-windows-driver-utility/
styles420 said:
It's the chip that is proprietary - those wifi cards use relatively well-documented chip sets, our phones do not. Unless you're aware of another device that uses the -exact- same chipset, with driver source code? (The question is rhetorical)
Feel free to guess at the unique opcodes and such, but trial and error will take a really long time
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
But the thing is that the samsung Galaxy S line of phones use what i can only imagine to be similar pieces of hardware. Wouldnt it make sense to be able to modify the drivers for say the fascinate`s camera or wifi for example to fit the epic. I know the keyboard isnt included in those phones but for the most part lines of phones tend to use similar if not the same hardware if they are made by the same companies. All it would take is to have the drivers for one or two of the phones in the same line and you would be able to practically guess the opcodes etc for the hardware signatures and make drivers accordingly. I mean a good example of this was when the fascinate drivers were used to boost our GPS or the fact that our CM7 is based off of the nexus S`version of CM7. It simply means that we have very similar if not the same hardware in most places. Now obviously if the phone is a random standalone piece with completely unique hardware then of course the drivers would be impossible to build with out the right specs and opcodes etc.
Actually on a side note, Ive been thinking about why the companies dont make a database for the drivers for each android phone effectively makeing each phone a nexus phone. It would allow for a version of android to be molded onto the phone with ease using a cookie cutter design making the creation of a newer phone easier and the support of older ones more feasible.
metalblaster said:
But the thing is that the samsung Galaxy S line of phones use what i can only imagine to be similar pieces of hardware. Wouldnt it make sense to be able to modify the drivers for say the fascinate`s camera or wifi for example to fit the epic. I know the keyboard isnt included in those phones but for the most part lines of phones tend to use similar if not the same hardware if they are made by the same companies. All it would take is to have the drivers for one or two of the phones in the same line and you would be able to practically guess the opcodes etc for the hardware signatures and make drivers accordingly. I mean a good example of this was when the fascinate drivers were used to boost our GPS or the fact that our CM7 is based off of the nexus S`version of CM7. It simply means that we have very similar if not the same hardware in most places. Now obviously if the phone is a random standalone piece with completely unique hardware then of course the drivers would be impossible to build with out the right specs and opcodes etc.
Actually on a side note, Ive been thinking about why the companies dont make a database for the drivers for each android phone effectively makeing each phone a nexus phone. It would allow for a version of android to be molded onto the phone with ease using a cookie cutter design making the creation of a newer phone easier and the support of older ones more feasible.
Click to expand...
Click to collapse
Well I guess sprint is only carrier using Wimax and above mentioned Wimax chips are only used in Epic. So to say this phone looks quite unique in that perspective though I think Nexus S 4G uses same chip, I couldn't find evident link pointing to it will report back as I do
rocket321 said:
I'm glad to see some answers on this topic as I was curious about it as well. Can anyone comment on how past drivers have been hacked? E.g. how the Evo got Wimax working in cyanogen? Did they just trial and error the hell out of it until everything worked or did someone get inside information?
Click to expand...
Click to collapse
I can't speak for the Evo Wimax people, but usually manufacturers that want to obscure their register set package up all the real meat in a userspace library, and distribute an open-source middleman kernel driver that basically relays commands through the middleman to the hardware (getting past the GPL).
Nvidia sorta does this, but they just link against the middleman directly and say F*** the GPL, even though it's still argued to be a violation.
Anyhow, for reverse-engineering, you can generally hack the middleman and record the 1's and 0's. Then you can attempt to decipher the data format based on what data changes, and the size of the frames. The stuff that doesn't change you can play back.
Of course, having any information about the device whatsoever helps a lot. I wouldn't be surprised if a hardware manual leaked for the Evo WiMax chip.
This is how a lot of the reverse-engineering was done on the HTC Vogue, the old device I developed for.
My life prevents me from helping at the moment, I hope to contribute on CM7 when things settle down.
jnadke said:
I can't speak for the Evo Wimax people, but usually manufacturers that want to obscure their register set package up all the real meat in a userspace library, and distribute an open-source middleman kernel driver that basically relays commands through the middleman to the hardware (getting past the GPL).
Nvidia sorta does this, but they just link against the middleman directly and say F*** the GPL, even though it's still argued to be a violation.
Anyhow, for reverse-engineering, you can generally hack the middleman and record the 1's and 0's. Then you can attempt to decipher the data format based on what data changes, and the size of the frames. The stuff that doesn't change you can play back.
Of course, having any information about the device whatsoever helps a lot. I wouldn't be surprised if a hardware manual leaked for the Evo WiMax chip.
This is how a lot of the reverse-engineering was done on the HTC Vogue, the old device I developed for.
My life prevents me from helping at the moment, I hope to contribute on CM7 when things settle down.
Click to expand...
Click to collapse
Thanks
However I don't understand most of it.
I've done until now is micro controller programming (say 8051 and similar)
Compiling kernel/FS for running on FPGA and few small boards, it was just compiling so I can set up tool chain and stuff but never actually developed / reverse engineered.
I would like to learn if u can point me to a good source.
wis3m0nkey said:
Thanks
However I don't understand most of it.
I've done until now is micro controller programming (say 8051 and similar)
Compiling kernel/FS for running on FPGA and few small boards, it was just compiling so I can set up tool chain and stuff but never actually developed / reverse engineered.
I would like to learn if u can point me to a good source.
Click to expand...
Click to collapse
Fortunately for you, the best book is free.
http://lwn.net/Kernel/LDD3/
Start with Chapter 1, I'd read all of that.
In general, I'd go through every chapter there and read the introductions. Stop once it gets to code. Those parts are irrelevant. The introductions alone are a powerful primer on how Operating Systems communicate with hardware.
Chapter 9: Communicating with Hardware is useful, since you're a hardware background.
Now, hacking android phones doesn't typically involve writing device drivers, but that book does a superb job outlining linux kernel interaction with hardware, which is the base of android. It is probably the quintessential book for anything Linux, and it's free!
jnadke said:
Fortunately for you, the best book is free.
http://lwn.net/Kernel/LDD3/
Start with Chapter 1, I'd read all of that.
In general, I'd go through every chapter there and read the introductions. Stop once it gets to code. Those parts are irrelevant. The introductions alone are a powerful primer on how Operating Systems communicate with hardware.
Chapter 9: Communicating with Hardware is useful, since you're a hardware background.
Now, hacking android phones doesn't typically involve writing device drivers, but that book does a superb job outlining linux kernel interaction with hardware, which is the base of android. It is probably the quintessential book for anything Linux, and it's free!
Click to expand...
Click to collapse
Awesome, thanks.
I'm not sure how much time it will take me but I'll try my best and probably will bother u some more
Hey, I'm a noob, let's get that out of the way first.
Alright, so I'd like to know, why is it so hard to get special ROMs working on certain devices?
For example, I have an Evo 3D (HTC Evo V 4G, whatever), so why is it so hard to get, say, stock ICS running on it?
Inthe end, isn't the hardware all the same, other than say processors and screen size? To get a stock ICS ROM working, couldn't you just pull it off of a similar phone with an S3 processor and a 4.3 inch screen?
Or is it not that simple? Are different codes baked into the hardware that make it impossible to just modify the pixel density, size of the screen and have the ROM work with the processors?
I understand the cameras are different, hence cameras not working on early builds of CM9... but considering many phones run the same processors, couldn't they just all work?
Please explain... thanks, thebeastglasser.
thebeastglasser said:
Hey, I'm a noob, let's get that out of the way first.
Alright, so I'd like to know, why is it so hard to get special ROMs working on certain devices?
For example, I have an Evo 3D (HTC Evo V 4G, whatever), so why is it so hard to get, say, stock ICS running on it?
Inthe end, isn't the hardware all the same, other than say processors and screen size? To get a stock ICS ROM working, couldn't you just pull it off of a similar phone with an S3 processor and a 4.3 inch screen?
Or is it not that simple? Are different codes baked into the hardware that make it impossible to just modify the pixel density, size of the screen and have the ROM work with the processors?
I understand the cameras are different, hence cameras not working on early builds of CM9... but considering many phones run the same processors, couldn't they just all work?
Please explain... thanks, thebeastglasser.
Click to expand...
Click to collapse
Is not that easy! I'm an EVO user/rom porter and I hear this alot where users such as yourself think is an easy process BUT is not. Same processor, same screen size maybe the same BUT at times the kernel is not there. Either the kernel for the device doesn't support ROM A or ROM B and therefore it can't be ported to whatever device or the libs keep it from running half way decent.....i.e WiFi doesn't work, sound is **** up or whatever the case maybe...just not functional to say the least.
Take for example Sense 4.0 on the One V....it was ported to the EVO4g and the ROM barely works! Both the One V and the EVO4g have similar hardware but one runs Sense 4.0 like a dream and the other one struggles with simple things like WiFi and Sound.
Now I'm sure someone else with a bit more knowledge on this can get into the specifics and the why's and what's of WHY this can't happen BUT that's it in a nut shell.....the kernel and 9/10 times libs
See ya around dude!
Hey first off, thanks! Second...
Another question then. If they all have relatively similar hardware, why isn't it that a universal kernel for similar phones can't be created?
Or better explained, what about the phone, makes it so that the kernel doesn't work? Or why couldn't you just take the kernel from device A and shove it on device B?
Sorry if I'm overloading you with questions, but hey I'm curious. Ya know?
EDIT: Or if they're practically both the same phones, why is it that you can't just take the ROM AND the kernel from phone A and put it onto phone B?
thebeastglasser said:
Hey first off, thanks! Second...
Another question then. If they all have relatively similar hardware, why isn't it that a universal kernel for similar phones can't be created?
Or better explained, what about the phone, makes it so that the kernel doesn't work? Or why couldn't you just take the kernel from device A and shove it on device B?
Sorry if I'm overloading you with questions, but hey I'm curious. Ya know?
EDIT: Or if they're practically both the same phones, why is it that you can't just take the ROM AND the kernel from phone A and put it onto phone B?
Click to expand...
Click to collapse
It's the manufacturer of the device who would need to release the kernel sources for the certain firmware version which they won't do continuously. In other words, device A may get ICS, hence the kernel sources may be released, but device B may be stuck with gingerbread and may not have a kernel which supports ICS. Back-porting can be done, but in many cases it is very difficult and in the end there still could be a lot of bugs.
You can't just take a kernel and "shove" it in another device. If you did this, it's quite likely nothing would work. The device would not even boot. Remember, the kernel is the center of android (Linux), so everything needs to be "linked" and correspond with each other exactly for it to work (I'm trying to make it as simple as possible ).
If they are the same devices, that would not be necessary. They would use the same roms/kernels. If they are just very similar (e.g. the a100 and a500) you may have some luck with the roms, but not the kernel. Some a500 roms can be flashed onto an a100 and work flawlessly BUT the device's original kernel must be restored for the device to boot.
Theonew said:
It's the manufacturer of the device who would need to release the kernel sources for the certain firmware version which they won't do continuously. In other words, device A may get ICS, hence the kernel sources may be released, but device B may be stuck with gingerbread and may not have a kernel which supports ICS. Back-porting can be done, but in many cases it is very difficult and in the end there still could be a lot of bugs.
You can't just take a kernel and "shove" it in another device. If you did this, it's quite likely nothing would work. The device would not even boot. Remember, the kernel is the center of android (Linux), so everything needs to be "linked" and correspond with each other exactly for it to work (I'm trying to make it as simple as possible ).
If they are the same devices, that would not be necessary. They would use the same roms/kernels. If they are just very similar (e.g. the a100 and a500) you may have some luck with the roms, but not the kernel. Some a500 roms can be flashed onto an a100 and work flawlessly BUT the device's original kernel must be restored for the device to boot.
Click to expand...
Click to collapse
I have the strangest feeling I just tried to jump into the shallow end of the swimming pool, and yet instead was shot out of a cannon into the middle of the sea without a scuba diver's suit... If only I could understand this more!
thebeastglasser said:
I have the strangest feeling I just tried to jump into the shallow end of the swimming pool, and yet instead was shot out of a cannon into the middle of the sea without a scuba diver's suit... If only I could understand this more!
Click to expand...
Click to collapse
Think about it this way. The Android OS could be run on a number of different devices that run slightly different hardware such as cameras, touchscreens, processors, etc...but the OS has to be able to communicate properly to that hardware using device drivers. Just like Windows from a 30000 foot view. It can run on a Dell or Acer computer, but must have the proper drivers.
If the manufacturer's of those devices do not write ICS drivers or preferably furnish their source code, then it is incredibly difficult if not impossible for someone without the internal company documentation to write such a driver.
mf2112 said:
Think about it this way. The Android OS could be run on a number of different devices that run slightly different hardware such as cameras, touchscreens, processors, etc...but the OS has to be able to communicate properly to that hardware using device drivers. Just like Windows from a 30000 foot view. It can run on a Dell or Acer computer, but must have the proper drivers.
If the manufacturer's of those devices do not write ICS drivers or preferably furnish their source code, then it is incredibly difficult if not impossible for someone without the internal company documentation to write such a driver.
Click to expand...
Click to collapse
Ohhh... so say you decided to put your own little phone together according to your own prerequisites, it'd be simple for you to do something on it, but not so much for someone who only has the hardware to look at... correct?
Another question, why is it so easy to port things onto Nexus Devices? Are they just more compatible with all drivers? As I've heard from one of my friends that he has a fully working Sense 4 ROM on his Nexus S... and yet it's tough to find one for my Evo V.
EDIT: I'm out of "thanks" I'll give you one as soon as I get some more...
thebeastglasser said:
Ohhh... so say you decided to put your own little phone together according to your own prerequisites, it'd be simple for you to do something on it, but not so much for someone who only has the hardware to look at... correct?
Another question, why is it so easy to port things onto Nexus Devices? Are they just more compatible with all drivers? As I've heard from one of my friends that he has a fully working Sense 4 ROM on his Nexus S... and yet it's tough to find one for my Evo V.
EDIT: I'm out of "thanks" I'll give you one as soon as I get some more...
Click to expand...
Click to collapse
Hmmm, I am not as familiar with the Nexus devices, but I suspect that Google has released the hardware spec details and the source code for the drivers for Nexus phones, so the source code can be modified and included for the ports. HTC unfortunately has not been as open with some of their phones.
If you were to put a phone together, you would need to use hardware in it that you had access to the specs and source code for. This is not a great analogy, but I think it will serve. The camera app tells the OS, "take a picture", then the OS tells the driver, "make the camera take a picture", and the camera device driver controls the hardware parts like the shutter, the focus, and zoom to cause the picture to be taken and handed back to the OS to be saved and then the OS notifies the app, "here is your picture, awaiting next command".
If you do not have access to the camera driver source code and camera hardware specs to create a driver, or an actual driver from the camera manufacturer, then you are missing the crucial third part and you cannot make the camera take a picture even if you get an OS loaded and an app installed there.
Check out The Tricorder Project for an excellent example. Create your own Star Trek "tricorder" with various sensors and a touchscreen that runs on Linux for around $200 and some work putting it together.
thebeastglasser said:
Ohhh... so say you decided to put your own little phone together according to your own prerequisites, it'd be simple for you to do something on it, but not so much for someone who only has the hardware to look at... correct?
Another question, why is it so easy to port things onto Nexus Devices? Are they just more compatible with all drivers? As I've heard from one of my friends that he has a fully working Sense 4 ROM on his Nexus S... and yet it's tough to find one for my Evo V.
EDIT: I'm out of "thanks" I'll give you one as soon as I get some more...
Click to expand...
Click to collapse
Its easy to develop for nexus devices since Google always releases their sources and those devices are easily unlockable (the bootloader). This is one reason why they are usually referred to as development/developer devices.
So in other words, the software communicates with the hardware, but without the proper code embedded in the hardware, it's not possible for the software to communicate with it? And without source code given from the developer of the hardware, you're making software that hypothetically should work, but because of the different device hardware it may or may not work...?
And that's also big because some guy on the portal recently found out that all of the eight mega pixel cameras on HTC devices are the same, so it should now be easy to use working cameras on ported and newly created ROMs...
Am I getting anywhere with this?
thebeastglasser said:
So in other words, the software communicates with the hardware, but without the proper code embedded in the hardware, it's not possible for the software to communicate with it? And without source code given from the developer of the hardware, you're making software that hypothetically should work, but because of the different device hardware it may or may not work...?
And that's also big because some guy on the portal recently found out that all of the eight mega pixel cameras on HTC devices are the same, so it should now be easy to use working cameras on ported and newly created ROMs...
Am I getting anywhere with this?
Click to expand...
Click to collapse
Yes, you got it a bit better now. The software needs to have the same codes embedded in the hardware to correspond with it. The source code is not from the hardware but of the software (kernel source).
Yes if the ROM was ported to other HTC devices with the same/similar camera (some libs will still need to be changed though).
Theonew said:
Yes, you got it a bit better now. The software needs to have the same codes embedded in the hardware to correspond with it. The source code is not from the hardware but of the software (kernel source).
Yes if the ROM was ported to other HTC devices with the same/similar camera (some libs will still need to be changed though).
Click to expand...
Click to collapse
Alright that makes a bit more sense. Thanks for your help guys!
Not really a technical question but I was wondering what we "noobs" and devs that aren't working on the 3.0.8 kernel can do to speed up or help in the development (we're all in this together right!?) Donations may help but are there any builds we can test with alogcats or just repetitive labor that manpower can aid in? If so feel free to put it here. One tip, guides to non intuitive stuff would help because like I said there are a quite a few noobs lurking (me included). Hopefully this is in the right thread I was contemplating putting it on the general but I wasn't sure.
I'm sure if they needed our help they would ask as they know many of us want to help. Best thing to do is just be patient and not bug them.
I guess you can help by flashing the build posted in the cm9 thread and reporting any bugs that haven't already been reported.
Sent from my SGH-T959V using xda app-developers app
This is a terrible way to get on the good book. Just fork bhundvens github repo. Make changes that work or look good, then push a pull request, then you'll be good.
Also, its called Aries not aires
Sent from my SGH-T959V using xda premium
Sit tight, let Bryan do his thing, and enjoy it when it gets here.
Sent from my SGH-T959V using xda premium
gregcapps said:
Sit tight, let Bryan do his thing, and enjoy it when it gets here.
Sent from my SGH-T959V using xda premium
Click to expand...
Click to collapse
A passive approach works too
Educate me what is Aries?
Bitcloud30 said:
Educate me what is Aries?
Click to expand...
Click to collapse
It is the proper Kernel for ICS which is more stable and offers better battery life. More specifically it is the machine type of the phone. Currently all builds are herring.
it's not a "Proper Kernel" per se.
Just the team hacksung people created a generic kernel to work with for all the Galaxy S 1 devices. Well, there are alot more devs over there and that's what's officially supported by CM. So now we are trying to merge into the official Galaxy S CM kernel.
Correct me if I'm wrong but Aries is the processor that our phone runs on it is hardware not software meaning it is a physical component that can't be changed by flashing any files
Sent from my SGH-T959V using xda app-developers app
anoymonos said:
Correct me if I'm wrong but Aries is the processor that our phone runs on it is hardware not software meaning it is a physical component that can't be changed by flashing any files
Sent from my SGH-T959V using xda app-developers app
Click to expand...
Click to collapse
nope, the processor is hummingbird. too many codenames. :silly:
also known as Exynos which is what anoymonos was getting confused with.
One of the big reasons to get on a kernel based on the Aries source is that it makes it a lot easier to move forward with AOSP releases. Right now, "our" kernel is a bit of AOSP, a bit of Samsung stock, a bit of TeamAcid work, a bit of TeamHacksung, a bit of..., so every time something comes up, it is a "custom job" to add it. I won't say that getting closer to mainline code will make JB a slam dunk, but without it, it would likely be lipstick on the pig.
Aries and Herring are Board Names (think motherboard).
Exynos and s5pc110 are Processor Names (both are SoC with the RAM in a PoP configuration).
Herring is the board name used for the nexus one and nexus s in Google's AOSP Samsung source.
The main board definition file for herring is: mach-herring.c
When Samsung worked with t-mobile, at&t, verizon, etc... to make Galaxy S phones, they basically reused the AOSP Samsung kernel for multiple devices. For instance, if you look at our UVKJ6 kernel drop, you will notice ifdefs in there for VIBRANTPLUS (Galaxy S 4G), KEPLER (Captivate), DEMPSEY (Infuse 4G), and a few others.
Aries is the main board definition file for the stock kernel is: mach-aries.c
Even though the board name is still herring. Ger.
They basically copied mach-herring.c to mach-aries.c and made their changes in mach-aries.c.
The Aries kernel, like jeffsf mentioned, is a kernel made by teamhacksung to be a combined kernel for galaxy s devices, and they use mach-aries.c and the aries board name.
If you get the stock kernel drop for any of these other devices in the same kernel drop from their respective drop, there will be subtle differences between each kernel drop. (crazy huh?)
And every file that samsung touches gains tens of lines of ifdefs, sometimes conflicting, as well as code that was '#if 0'ed out because they didn't code it right and left some other variable definitions without also '#if 0'ing them as well leaving nasty build warnings.
If you don't know anything about embedded devices, linux kernel development, or kernel debugging, just lay back and chill. We're getting close, just some nasty rough edges to clean up.
If you do have one or more of those skills, join us in #teamacid.
As it stands right now, most of the problems are GPIO issues. I am having a rough go at figuring out our GPIO configuration for this phone. Everytime I think I figure out something I find that I am wrong.
Also, to make things harder and more confusing, unlike the stock kernels, the aries kernel puts the GPIO pin configuration right in mach-aries.c, where as stock kernels put them in include/mach/gpio-settings-<devicename>.h... :sigh:
Hopefully m4xm4n and jeffsf can give me a hand with this stuff.
It would be nice if some teamhacksung members could give a hand and some guidance.
bhundven said:
Aries and Herring are Board Names (think motherboard).
Exynos and s5pc110 are Processor Names (both are SoC with the RAM in a PoP configuration).
Herring is the board name used for the nexus one and nexus s in Google's AOSP Samsung source.
The main board definition file for herring is: mach-herring.c
When Samsung worked with t-mobile, at&t, verizon, etc... to make Galaxy S phones, they basically reused the AOSP Samsung kernel for multiple devices. For instance, if you look at our UVKJ6 kernel drop, you will notice ifdefs in there for VIBRANTPLUS (Galaxy S 4G), KEPLER (Captivate), DEMPSEY (Infuse 4G), and a few others.
Aries is the main board definition file for the stock kernel is: mach-aries.c
Even though the board name is still herring. Ger.
They basically copied mach-herring.c to mach-aries.c and made their changes in mach-aries.c.
The Aries kernel, like jeffsf mentioned, is a kernel made by teamhacksung to be a combined kernel for galaxy s devices, and they use mach-aries.c and the aries board name.
If you get the stock kernel drop for any of these other devices in the same kernel drop from their respective drop, there will be subtle differences between each kernel drop. (crazy huh?)
And every file that samsung touches gains tens of lines of ifdefs, sometimes conflicting, as well as code that was '#if 0'ed out because they didn't code it right and left some other variable definitions without also '#if 0'ing them as well leaving nasty build warnings.
If you don't know anything about embedded devices, linux kernel development, or kernel debugging, just lay back and chill. We're getting close, just some nasty rough edges to clean up.
If you do have one or more of those skills, join us in #teamacid.
As it stands right now, most of the problems are GPIO issues. I am having a rough go at figuring out our GPIO configuration for this phone. Everytime I think I figure out something I find that I am wrong.
Also, to make things harder and more confusing, unlike the stock kernels, the aries kernel puts the GPIO pin configuration right in mach-aries.c, where as stock kernels put them in include/mach/gpio-settings-<devicename>.h... :sigh:
Hopefully m4xm4n and jeffsf can give me a hand with this stuff.
It would be nice if some teamhacksung members could give a hand and some guidance.
Click to expand...
Click to collapse
Hopefully you get the help you need. Hey here's a dumb question, could you not call the manufacturers of the phone and ask them what the gpio config is?
IIRC the gpio functions are part of a proprietary code source. So no Samsung will not tell you.
eollie said:
IIRC the gpio functions are part of a proprietary code source. So no Samsung will not tell you.
Click to expand...
Click to collapse
The GPIO pins are signal pins on the SoC that allow you to connect external devices to the main cpu.
It is actually specific to the board because each phone have different connected devices (such as lcd panel, wifi, touch screen, etc...).
The GPIO pins and interrupt signals are all documented in the S5PC110 User Manual, but the pin layout in that manual is specific to the reference board it is describing. Each phone/device has its own GPIO layout and it is specific to the schematic.
Sure wish we had a vibrantplus schematic.
airfluip1 said:
it's not a "Proper Kernel" per se.
Just the team hacksung people created a generic kernel to work with for all the Galaxy S 1 devices. Well, there are alot more devs over there and that's what's officially supported by CM. So now we are trying to merge into the official Galaxy S CM kernel.
Click to expand...
Click to collapse
OK...maybe not a "proper" kernel technically , but certainly a whole lot closer to what to we need to have a better experience with the newer versions of android os.
Sent from my SGH-T959V using xda premium
you aren't wrong. I just explained it a bit.
@othern00bs
Here is a simple way to put it for the others who are confused
CyanogenMod Team made kernel = aries = more polished = newer kernel version = we can get regular kernel/version updates because the team acid members won't have to manually port them = potentially Jellybean in the long run (as soon as ICS is polished)
TeamAcidMTD kernel = herring = older version ported to work with ICS = needed to port again for JB = buggier = degraded bat life = manually having to port each change and CM version
bhundven said:
Sure wish we had a vibrantplus schematic.
Click to expand...
Click to collapse
What, the 2426 pages of S5PC110 manual aren't enough bedtime reading for you?
(No, the page count is not a joke.)
Well, I agree that getting Some Hacksung member on IRC should help you.
The dev community for Samsung tab's is minimal for such a great Tablet not saying others brands are bad but seriously I owned or did own a Samsung i9505 until my son washed it with soap and water lol however the dev support for a telephone or mobile phone was insane, for this tablet and the lack of support for such an out standing device is kinda weird in a way, and its only just over a 1 1/2 old, i still own a Motorola xoom which devs gave support for while over 3 years , you had almost every dev working on a project for that slow old device, Samsung tabs are one of the best and what we have here is nothing for LP (lolliopop) with TW,(touchwiz) i mean hell, the TW for the I9505 you could add themes with the tab models there are no theme engine unless you switch to cm, i fully support cm and there crew but im a stock sorta guy where i take advantage of the devices features. cm doesn't really support a device to device development and all its modules ie IR blaster, Peel Application's or have the nice and neat multi window tool bar i know with xposed you can get them sorta things but to end it like this these devices need more juice from the development department.
no need to flame me i know but its just my 2 cents.
Thanks for reading lol
I bought a galaxy player (think ipod, but running on android) a few years back and it didn't attract very many developers either. I'd guess non-phones just don't interest as many people.
Also, it's not THAT hard to make your own rom.
Find a rom with most of the features you like
Decompile/decompress that rom into it's component files
Modify the files as you like (change optimizations, add features/tools from other roms, change the installer, update the kernel, etc.)
Compile the modified files back into a single rom image
Test and troubleshoot (you'll loop through this step many many times)
(optional) publish on xda
The hardest part of customizing a rom is building the dev. environment. This usually means installing linux on a virtual machine (which takes a bit of learning itself), and getting the tools installed and running isn't something you can do by a rote process (there's almost always some dependency missing, so you need to be able to understand the error messages to determine what you need to add/fix).
However, if you're comfortable with installing a custom rom and unbricking a device, that should be within your skill level. You'll probably need to use a half dozen walkthroughs for each of the trickier tools, or errors you may encounter, and end up spending a few days all total just getting it set up. Thankfully that's a one time process, and even if, by some horrible misfortune, you have to do it again, it'll take a fraction as long the 2nd time.