I need a straight answer as it's possibly the one thing I can't figure out.
For eclair, NCommander fixed camera, but camcorder and video were broken from a straight build from AOSP.
CM later fixed these, but I never quite figured out how. Then everybody else started getting the camera fixed on their roms (by pulling a couple libs, I assume), but I myself couldn't figure out how the heck it was done, where an alternate source was available, or even an explanation of exactly what was broken/how it was fixed, etc. Same went for video playback/hw acceleration.
Now, on froyo, camera is broken again and NCommander's camera won't work either. It's been fixed by other people, but when I ask around, there seems to get a reluctance and I never really get an answer (and don't give me the "you're not asking the right question" line, I'm being pretty straightforward).
I need somebody here who has some knowledge as to why/how camera/hw is not working and how to fix it. I don't need libs. I need to know how to get the thing built from AOSP, why it breaks, and what I should look out for in the future, should it break again.
As far as I can tell, the problem is that the qcomm proprietary parts are outdated (for dream, last were 1.6 and eclair/froyo break compatibility with those libraries). Those libraries have to be linked-to at compile time of other hardware-libs and without the correct library, it won't build right.
What I don't get is: 1. which parts are missing, 2. where are people getting them from, 3. how do you add them to AOSP (other than PRODUCT_COPY_FILES) to get camera and all hw working right (including 3d acceleration).
Or maybe the project aurora community is better able/willing to help...
Bump. Totally interested. If OP already got an answer, please share.
Jubeh sorry I can't help you out I'm not a dev or a chef so I can't really give you any help. But I am interested in how your progress is going with this rom?
I found two sources for hardware files for the msm7k on our phones, including the camera and hw3d driver for dream. Also, building camera for AOSP seems to be fixed now. I'm just waiting from my battery to get here so that I can test. ebay parts from hong kong take forever.
http://www.androidpolice.com/2012/11/13/breaking-android-4-2-being-released-to-aosp/
I know, it's just out so we can't be sure of anything. But I was wondering if CM11 was planned for the 10.1v if it doesn't ask for too much efforts. It's a 4.x update so I would guess it won't break a lot of things. But who knows. The CM10 are still considered experimental after all although they are quite stable, so it might not happen officially ?
So many questions, so much patience to have that I don't...:laugh:
DannyBiker said:
http://www.androidpolice.com/2012/11/13/breaking-android-4-2-being-released-to-aosp/
I know, it's just out so we can't be sure of anything. But I was wondering if CM11 was planned for the 10.1v if it doesn't ask for too much efforts. It's a 4.x update so I would guess it won't break a lot of things. But who knows. The CM10 are still considered experimental after all although they are quite stable, so it might not happen officially ?
So many questions, so much patience to have that I don't...:laugh:
Click to expand...
Click to collapse
I dont think that 4.2 is going to be CM11. Its still Jelly bean after all. I think that our only hope is that its as simple as updating the sources used to compile CM10. Then theoretically it should just slot right in there, the way that 4.1.2 did (although I dont know the actual required work in getting our device from 4.1.1 to 4.1.2), and then hopefully Pershoot could just run a new experimental build for us. Im loving his last CM10 experimental by the way. I dont seem to be having any of the previously mentioned issues.
However, with the age of our device getting closer to two years, Pershoot has been a godsend (along with isimobile and also Seo's coding work previously), but I couldnt ask him to move onto the hassles of a whole new version for us, especially if its not a simple change.
Yeah, if updating to 4.2 would ask too much work, at least to get a stable release, I wouldn't mind that all the effort are focused on bringing a final 4.1 rom for the tab and end development for it. If 4.2 is possible, that'd be great but I guess it would be the last version for us.
All in all, we won't ever be grateful enough for what you do for us pershoot. I know you don't want donations, so I'll just donate to CM instead...
4.2 has changes in Surface Flinger to support multiple screens. I made quick build for P3 and out of the box 4.2 is not compatible with current Nvidia binaries, surface flinger hangs at "create window surface". So unless we can mend 4.2 surface flinger to work with ICS nvidia binaries, this could be end of the road for Tegra 2 devices. Since Google ditched Xoom, hope is even smaller... Other option would be port 4.1.2 Surface Flinger to 4.2....could be useful for other devices though...
Well I just hope then we'll be able to implement some content of 4.2 like the lockscreen, the timer app or the multi-account feature...:good:
with some hacks in Surface Flinger, I actually managed to get surfaces flinger initialized, and now boot animation is working so there might be still chance .... it crashed later on in multimedia though, so still plenty of work.
But yeah, would be nice to back port some 4.2 things, though it might be easier to move 4.1 surface flinger to 4.2, at least if graphic drivers proof to be main issue for upgrade...
Any idea on how simple users like me can help beside beta-testing when the time will come ? Are there devices that we might need to check out as they may help us with this port ?
Thanks !
EDIT : also, I imagine that after some point, you'll share your work with pershoot.
OndraOrg said:
with some hacks in Surface Flinger, I actually managed to get surfaces flinger initialized, and now boot animation is working so there might be still chance
Click to expand...
Click to collapse
Can you tell me what you've changed?
But yeah, would be nice to back port some 4.2 things, though it might be easier to move 4.1 surface flinger to 4.2, at least if graphic drivers proof to be main issue for upgrade...
Click to expand...
Click to collapse
I don't think that this will be easy. There are so much changes in surfaceflinger 4.2, especially the interface has changed. You would have to port the hwcomposer interface from 4.1, but leave the rest of the interface unchanged. Otherwise the rest frameworks/native breaks.
C-o-M said:
Can you tell me what you've changed?
New surface flinger was not loading grallock component at all. So I added in display device call to load grallock, then attempt to create main window surface succeeds. I also tweak api version bit, to accept current version, though I don't think that was the issue, grallock was the main problem. But I can't really confirm if this is enough, since there are more crashes along the line in other components, so all I can see is android boot animation. But surface flinger composition must be working to some degree. And there are no more obvious errors from Surface Flinger.
Now problem is in Audio flinger, which is another component quite modified, it makes some calls to audio_policy.tegra.so with ilegal parameters. So similar issue as with graphics. I commented out this call, but then Dalvik VM crashed with some weird error. Let's see when I have more time.
I don't think that this will be easy. There are so much changes in surfaceflinger 4.2, especially the interface has changed. You would have to port the hwcomposer interface from 4.1, but leave the rest of the interface unchanged. Otherwise the rest frameworks/native breaks.
Click to expand...
Click to collapse
Agree here. My motivation for surface flinger port was a) this effort could be useful also for other devices which were left behind for 4.2 upgrade. b) while new Surface Flinger has many changes, lot of them are related to new multi screen functionality. That could be stubbed on api level (binder interface doesn't actually have that many changes). I bet many ppl would prefer to have 4.2 functionality, and loose HDMI functionality.
Problem I can see is that we don't know how many components we would need to port like this. Seeing now crashes in Audio Flinger, this can be lot bigger issues. There is new bluetooth stack in 4.2, replacing Bluez. If those close code binaries are using Bluez and same api does not exist in 4.2, we're in trouble.
OndraOrg said:
New surface flinger was not loading grallock component at all. So I added in display device call to load grallock, then attempt to create main window surface succeeds. I also tweak api version bit, to accept current version, though I don't think that was the issue, grallock was the main problem. But I can't really confirm if this is enough, since there are more crashes along the line in other components, so all I can see is android boot animation. But surface flinger composition must be working to some degree. And there are no more obvious errors from Surface Flinger.
Click to expand...
Click to collapse
Thanks. I'll try do redo that.
C-o-M said:
Thanks. I'll try do redo that.
Click to expand...
Click to collapse
Let me know if it works for you, or I can share code...
C-o-M said:
Thanks. I'll try do redo that.
Click to expand...
Click to collapse
Actually it is working! Sorry I have just hour a day to play with this, that's why sporadic progress. Anyway after stubbing audio flinger and one call in dalvik, I managed to boot it. It's not usable since, since phone app crash report is all the time in the front. But UI is there. So that hack from surface flinger seems to be work after all
OndraOrg said:
Actually it is working! Sorry I have just hour a day to play with this, that's why sporadic progress. Anyway after stubbing audio flinger and one call in dalvik, I managed to boot it. It's not usable since, since phone app crash report is all the time in the front. But UI is there. So that hack from surface flinger seems to be work after all
Click to expand...
Click to collapse
That's awesome. Do you have a diff for me? Or even a git?
Slightly edited the title as you started messing around with it, although we all know it's just "to see where's it going" for now...
C-o-M said:
That's awesome. Do you have a diff for me? Or even a git?
Click to expand...
Click to collapse
Need to still sort one thing about status bar, whole UI is in phone mode (status bar with soft keys in the middle, and notification bar at the top) and then I can share install package. Ui and wifi works fine, bluetooth and audio does not work. And I still have some issue with storage mapping. This has now new layout thanks to multiuser support.
OndraOrg, I think you need to read a bit about 4.2 : Tablet UI is gone, Phone UI has been pushed to all Android devices.
See this : http://www.androidpolice.com/2012/1...just-like-a-giant-phones-and-thats-fantastic/
OndraOrg said:
Need to still sort one thing about status bar, whole UI is in phone mode (status bar with soft keys in the middle, and notification bar at the top) and then I can share install package. Ui and wifi works fine, bluetooth and audio does not work. And I still have some issue with storage mapping. This has now new layout thanks to multiuser support.
Click to expand...
Click to collapse
I'm not interested in the install package. I'd like to get the source code to experiment on my tab 8.9.
C-o-M said:
I'm not interested in the install package. I'd like to get the source code to experiment on my tab 8.9.
Click to expand...
Click to collapse
OK I will clean code and get you diffs.
C-o-M said:
I'm not interested in the install package. I'd like to get the source code to experiment on my tab 8.9.
Click to expand...
Click to collapse
Here are my patches.
Dalvik patch will get you around storage issue in vm. You can remove it once you fix your boot image
framework-av will patch you crash with audio, though it will make audio not to work. Not sure if you will need this for your 8.9 tab
framework-native will patch you surface flinger, so it works with old binaries
OndraOrg said:
Here are my patches.
Dalvik patch will get you around storage issue in vm. You can remove it once you fix your boot image
framework-av will patch you crash with audio, though it will make audio not to work. Not sure if you will need this for your 8.9 tab
framework-native will patch you surface flinger, so it works with old binaries
Click to expand...
Click to collapse
Nice. Thought it was more to change.
have been using this rom since a month without problems and i got the "P" version of i9100 with nfc included, but obviously it not working with this rom. i'm thinking about of the implemetation on kernel of this option for i9100P users like me. i have been reading about that in xda, and i found this thread:
http://forum.xda-developers.com/showthread.php?t=1822447
but, its not continuous or seems to be stopped.
could be this feature implemented someday?
i think i found the driver of nfc chipset ,https://android.googlesource.com/ke...7456ef92735a1257c95eac44/drivers/misc/pn544.c
Edray said:
have been using this rom since a month without problems and i got the "P" version of i9100 with nfc included, but obviously it not working with this rom. i'm thinking about of the implemetation on kernel of this option for i9100P users like me. i have been reading about that in xda, and i found this thread:
http://forum.xda-developers.com/showthread.php?t=1822447
but, its not continuous or seems to be stopped.
could be this feature implemented someday?
i think i found the driver of nfc chipset ,https://android.googlesource.com/ke...7456ef92735a1257c95eac44/drivers/misc/pn544.c
Click to expand...
Click to collapse
The main problem is handling the fact that some of the NFC stuff behaves VERY badly if put into a device that doesn't have the hardware.
No one ever figured out a way to get it added to the P without either having a separate build or breaking the non-P I9100.
Although with the new infrstructure for "unified" device builds, this might now be possible.
As an FYI, the I777 (which REQUIRES a different build due to having different call audio, touchkeys, and a few other things) has NFC. The main blocker on the P was not wanting to create yet another build.
and it will be not possible a flashable zip with NFC enabler, and a script like superSU for not being erased by the updates?
thanks for your reply:good:
Edray said:
and it will be not possible a flashable zip with NFC enabler, and a script like superSU for not being erased by the updates?
thanks for your reply:good:
Click to expand...
Click to collapse
We don't do separate flashable ZIPs and stuff like that. Our build system doesn't support it, among other things.
One more in the request
I join to the kind request for this feature. As you know, NFC is now of use for payment and ID (to enter your office, for example), so I hope it makes sense for you to consider the effort and risk of creating a separate version in a near future. I can't adopt any ROM wo NFC unless I carry additional ID/VISA cards (2 more in my crowded wallet).
bajajel said:
I join to the kind request for this feature. As you know, NFC is now of use for payment and ID (to enter your office, for example), so I hope it makes sense for you to consider the effort and risk of creating a separate version in a near future. I can't adopt any ROM wo NFC unless I carry additional ID/VISA cards (2 more in my crowded wallet).
Click to expand...
Click to collapse
Sorry, but adding NFC to the I9100P won't help you here.
AOSP is missing HCE support for any device with an NXP NFC chipset. Until that changes, the I777/I9100P will not be payment capable even if NFC is added for P builds.
Since at lease back in the 4.4 days of AOSP, the nexus 5 (and probably others) has had an issue with the camera when in video mode. There's a nasty green line that appears on the side of the video during playback.
It's an easy fix; just replace the file /system/lib/libmmcamera_interface.so with the one from the factory nexus image.
I have poured over the source code for this library, but I can't find out what it is that causes this anomaly nor why it is fixed in google's image, but not in the AOSP source. How can this have been an issue for so long? Am I the only one who runs self-compiled AOSP on my N5?
Anyway, does anybody have any idea what the cause is, or how to fix it in the source?
Hello!
I started searching to fix that issue this morning and i ran in to your post. Ive been building a while from aosp sources with minimal editing only, and i think this hasnt happened with 5.0.2 for me. Now that ive merged 5.1 into the source, i saw it happening again.
I checked few trusted developers vendors, blobs, etc. And i managed to make this:
https://github.com/sicknemesis/android_vendor_lge/commit/de6831773e3e083cef8d53f344f0a03f6a604268
As i write, im flashing and bootin a rom build with this commit and it seems its working correctly now.
All credits to original authors as seen in original commit! Hope this was the thing we are looking for and i see not lot of people check this Developer Discussion forum . I DO!
Gene Poole said:
Since at lease back in the 4.4 days of AOSP, the nexus 5 (and probably others) has had an issue with the camera when in video mode. There's a nasty green line that appears on the side of the video during playback.
It's an easy fix; just replace the file /system/lib/libmmcamera_interface.so with the one from the factory nexus image.
I have poured over the source code for this library, but I can't find out what it is that causes this anomaly nor why it is fixed in google's image, but not in the AOSP source. How can this have been an issue for so long? Am I the only one who runs self-compiled AOSP on my N5?
Anyway, does anybody have any idea what the cause is, or how to fix it in the source?
Click to expand...
Click to collapse
Wow, so the N5 was never intended to use the AOSP version of that library. I never checked the qcom binaries nor noticed that it was included there.
Thanks for this!
The Boot2Gecko people have a source fix for it:
https://bugzilla.mozilla.org/show_bug.cgi?id=1117662
https://github.com/mozilla-b2g/device-hammerhead/commit/c37663f828891cf7a49451a04f3f1ce7f7e5c054
Thanks. It appears that the same lack of patch exists in the M source. I'll try it when I get a chance.
First off, a little background.
The first few days after buying the Moto X I found MotoDisplay a little too sensitive and, to be honest, a little annoying that it would turn on all the time, but after a while I started getting used to it and subconsciously dependent on the way it works.
A few days ago I remembered using an application on my galaxy nexus which kind of did the same thing, and so I tried replacing MotoDisplay with one of the alternatives from the playstore. I chose AcDisplay and I really liked most of it's features (it's animations are beautiful). Except it doesn't use the IR sensors.
AcDisplay being an open source project, I thought to my self "I could probably implement a feature similar to MotoDisplay's extremely sensitive wave to wake up". So I looked for examples on how to use the IR Sensors and found none. I looked for an SDK/API and found nothing. I've looked at motorola's github and none of the repositories seemed to be what I wanted.
So the question is, how can I make a program that makes use of the Moto Xs IR sensors? Are there any resources on how to use them, or is this feature closed source and I'm not supposed to use it?
Apparently, apart from the official MotoDisplay, the only other project making use of these sensors is CM12 (which I haven't tried myself), which leads me to believe that it's not as simple as using the other, more common, sensors.
bump
evilnoxx said:
First off, a little background.
The first few days after buying the Moto X I found MotoDisplay a little too sensitive and, to be honest, a little annoying that it would turn on all the time, but after a while I started getting used to it and subconsciously dependent on the way it works.
A few days ago I remembered using an application on my galaxy nexus which kind of did the same thing, and so I tried replacing MotoDisplay with one of the alternatives from the playstore. I chose AcDisplay and I really liked most of it's features (it's animations are beautiful). Except it doesn't use the IR sensors.
AcDisplay being an open source project, I thought to my self "I could probably implement a feature similar to MotoDisplay's extremely sensitive wave to wake up". So I looked for examples on how to use the IR Sensors and found none. I looked for an SDK/API and found nothing. I've looked at motorola's github and none of the repositories seemed to be what I wanted.
So the question is, how can I make a program that makes use of the Moto Xs IR sensors? Are there any resources on how to use them, or is this feature closed source and I'm not supposed to use it?
Apparently, apart from the official MotoDisplay, the only other project making use of these sensors is CM12 (which I haven't tried myself), which leads me to believe that it's not as simple as using the other, more common, sensors.
Click to expand...
Click to collapse
You can look at the CyanogenMod CMactions source code. However, you are going to have selinux problems as you need to touch the raw driver to enable wakeups.
crpalmer said:
You can look at the CyanogenMod CMactions source code. However, you are going to have selinux problems as you need to touch the raw driver to enable wakeups.
Click to expand...
Click to collapse
That seems way to hard for me. Thank you anyway for the reply