• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root [DEV] WIP CM9 (Camera) [updated 2/23/2013]

OK....I am new to Android Development like this...so are there any instructions I can follow for how to develop?

And does the kernel driver currently hose the system as in the previous post?

You could alway post a new thread if you get stuck. I have set up my system a bunch of times and have learned git (you'll see what I mean) pretty well. Even if you goof up the build a bunch of times, there are ways of coming back.

Nandroid Nandroid Nandroid Nandroid Nandroid Nandroid Nandroid backup
 
There is to many issues with the 2.6.35 kernel and I don't know enough of what is wrong to make it work. Even though the x6 2.6.35 is our sister phone there is many differences in our kernel's.

it's almost like you are working harder now that you aren't working on the code LOL
 
It sure is helpful to have some pointers from the people that know what they're doing. I know this information is all out there, but it can take a lot of time to track down and sort through. So, thanks a ton for that summary g60, I'll see what portion of this mess I can get building.
 
Hey g man don't ever think you let anyone down dude. I mean we all wish we could bust out a perfect camera fix but the truth is its hard as sh*t and ain't no one else coming close to it. I can't even say I have contributed 1/32 of what you have for this phone. Everyone here, that matters, is grateful for everything you have done!!
 
Hey g60, I read through the whole thread, and it does look like you are close. I don't see where you are having trouble with C++, though. Is it QualcommCameraHardware.cpp? Is there some part of that I can help you with?

I'm looking through the code and at your latest logcat, and I can see where it is up to initPreview(), are those other messages after that coming from the closed source code?

I have worked with somewhat similar hardware before, and was hoping maybe there was a problem with the memory set aside for this closed source blob. But, it looks like that memory is dynamically allocated. Do we know how these addresses are passed to the blob?

It also looks like there are some kernel parameters associated with this memory area... do we know how those are set on the other phones this works on?

Just a couple thoughts I had after looking at this briefly. I'm building it now and it's failing on libcamera.so but I'm not even worried about that yet. I still want to try to understand the differences in all these kernels and camera drivers.

EDIT:
Is the vendor/proprietary/libcamera.so the same library we are building from source in hardware/msm7k/libcamera?
 
Well, I'm not sure if this is what the blob is using, but there is a bunch of info on the pmem that is working on CM7 in /sys/kernel/pmem_regions, and if the camera is using pmem_adsp, we are looking at starting address 0x9e00000 (size 0x2000000, but we knew that). I'm curious what these numbers looks like in CM9 (haven't taken the plunge with mine yet), and on the other phones. There are four of these memory regions, 3 for pmem and one for the framebuffer, so if these regions aren't laid out the same the blobs may not work. No idea if I'm barking up the wrong tree here, this stuff could be already handled...

Also, there is plenty of spam in dmesg about an mt9p111, which looks like our camera. Do we know that these sister phones have the same camera chip? It looks like the kernel has a bunch of camera chips enabled.
 
Hey g60, I read through the whole thread, and it does look like you are close. I don't see where you are having trouble with C++, though. Is it QualcommCameraHardware.cpp? Is there some part of that I can help you with?

Most of that was taken care of Dorrey as he has a greater understanding than I do.

I'm looking through the code and at your latest logcat, and I can see where it is up to initPreview(), are those other messages after that coming from the closed source code?

Again this would be Dorrey again

I have worked with somewhat similar hardware before, and was hoping maybe there was a problem with the memory set aside for this closed source blob. But, it looks like that memory is dynamically allocated. Do we know how these addresses are passed to the blob?

The only place I know of memory changes is
https://github.com/MTCM9/android_ke...s/arch/arm/mach-msm/board-msm7x30.c#L157-L175
Again my lack of Kernel skills.

It also looks like there are some kernel parameters associated with this memory area... do we know how those are set on the other phones this works on?

You best best is to look over tjstyles kernel or even abenagiel kernel. Both kernel's are for the X6

Just a couple thoughts I had after looking at this briefly. I'm building it now and it's failing on libcamera.so but I'm not even worried about that yet. I still want to try to understand the differences in all these kernels and camera drivers.

The best way to remember is this is our CameraHAL which creates the link from system/libs/libcamera.so to system/lib/hw/msm7x30.so with in the ROM. The libcamera2 is basically as close to stock libcamera built from source code. Dorrey set this up to allow us the ability to tweak the libcamera as needed to work. When the ROM builds it will create system/lib/libcamera2.so simple delete the stock Cherry libcamera.so and rename the libcamera2 to libcamera.so

EDIT:
Is the vendor/proprietary/libcamera.so the same library we are building from source in hardware/msm7k/libcamera?

Disregard this it does nothing. This is CyanogenMod Team's poor try at making a generic CameraHAL

Also, there is plenty of spam in dmesg about an mt9p111, which looks like our camera. Do we know that these sister phones have the same camera chip? It looks like the kernel has a bunch of camera chips enabled.

This very well maybe the case if you use Meld and look at our stock kernel and then look at our ICS kernel (make sure you are only using the ICS branch) you will see how many extra directories have been added. I truly feel that right now the Triumph has had way to many hands in the cookie jar (including mine) and I honestly believe to solve the camera we will need to take the stock kernel and apply ICS settings to it, and then and only then can we test the rest of ROM around it. This has been a fun project but IssacJ, Mantera, and myself, incuding I am sure some of TickerGuy's fixes could be still lingering in the mix which may or may not be the problem.

When I took over CM9 I broke 100% away from Mantera's build and used complete stock CM9 code and added in our patches for RIL, 3g, Wifi, GPS, Tethering. There is other parts of Mantera's code which may or may not been needed all his code, and repo is here.

https://github.com/mantera
$ repo init -u git://github.com/mantera/android.git -b ics
$ repo sync


The other thing to throw out there now that we are on the subject of Camera is all of TickerGuy's fixes he used to make the camera work in CM7. I spoke with Dorrey and he didn't feel these mattered at the moment as the Camera was still crashing but just so you know from a timeline stand point

https://github.com/tickerguy/android_system_core/commit/1d07b76bafa6d9ca8544aa039530d47f43f7a705

https://github.com/tickerguy/WX_435_Kernel-Tickerguy/commit/c470119326665000ac242a1f8791d60bd90f03ed

https://github.com/tickerguy/WX_435_Kernel-Tickerguy/commit/c3913e8fe7ec4d32acedc42bc518ef674620e2a2

https://github.com/tickerguy/android_frameworks_base/commit/3e9fd8fd5951c9f161334d2cc21d8bbbf5b1992a

If there is anything else let me know! Also sorry for the delay Comcast was down last night :p
 
This very well maybe the case if you use Meld and look at our stock kernel and then look at our ICS kernel (make sure you are only using the ICS branch) you will see how many extra directories have been added. I truly feel that right now the Triumph has had way to many hands in the cookie jar (including mine) and I honestly believe to solve the camera we will need to take the stock kernel and apply ICS settings to it, and then and only then can we test the rest of ROM around it. This has been a fun project but IssacJ, Mantera, and myself, incuding I am sure some of TickerGuy's fixes could be still lingering in the mix which may or may not be the problem.

When you say "stock kernel" here, this is the original source from Motorola?

Is this kernel a good reference to look at in terms of what is working in CM7?

https://github.com/MTDEV-CM7/WX_435_Kernel-CM7
 
When you say "stock kernel" here, this is the original source from Motorola?

Is this kernel a good reference to look at in terms of what is working in CM7?

https://github.com/MTDEV-CM7/WX_435_Kernel-CM7


When I say stock I mean the source code that Motorola gave us which is here

https://github.com/MTDEV-KERNEL/MOTO-KERNEL

That repo was taken from kernel download that Motorola gave us located here

Triumph WX435 - Browse /WX435/CAYM_D_0_1010_2039_BP_2037_CDA_1024 at SourceForge.net

The WX_435_Kernel is Whyzor's kernel which was again taken from CAF source code and diffed between our stock Motorola Kernel. My thought process is to roll with the stock kernel and get it working properly with CM9 and then added in changes for the overclock and stuff later. Again since I am no kernel guru this is just my thought process.

The reason I am on the stance is because in all actuality there is not one kernel being used that is stock. I believe all kernel's TickerGuy, IssacJ, Mantera, Whyzor and b_randon's kernels are all from merged CAF source code. I know there is lots of issues with all those kernel's and deep sleep and Wifi but the stock kernel deep sleep works fine with Wifi. I propose that if you can upgrade the 100% stock kernel everything should work properly as a lot of the hardware issues have been resolved in the code, and or can be fixed through the code.

The kernel is the spinal cord of the whole OS which I know you know. So in fixing that everything else should come together in my logic. Of course no one ever said my logic is sound :rolleyes:
 
The reason I am on the stance is because in all actuality there is not one kernel being used that is stock. I believe all kernel's TickerGuy, IssacJ, Mantera, Whyzor and b_randon's kernels are all from merged CAF source code. I know there is lots of issues with all those kernel's and deep sleep and Wifi but the stock kernel deep sleep works fine with Wifi. I propose that if you can upgrade the 100% stock kernel everything should work properly as a lot of the hardware issues have been resolved in the code, and or can be fixed through the code.

The kernel is the spinal cord of the whole OS which I know you know. So in fixing that everything else should come together in my logic. Of course no one ever said my logic is sound :rolleyes:

Ok, I didn't realize deep sleep worked with wifi in the stock kernel, that is quite interesting. It makes me think your idea of going back to the stock might be a good move.

What would be involved in upgrading the stock kernel? Just updating the camera portions, or are there some other pieces that need to be updated as well? Obviously there's the overclock stuff, but I just mean in terms of everything fundamentally working.
 
When I say stock I mean the source code that Motorola gave us which is here

https://github.com/MTDEV-KERNEL/MOTO-KERNEL

That repo was taken from kernel download that Motorola gave us located here

Triumph WX435 - Browse /WX435/CAYM_D_0_1010_2039_BP_2037_CDA_1024 at SourceForge.net

The WX_435_Kernel is Whyzor's kernel which was again taken from CAF source code and diffed between our stock Motorola Kernel. My thought process is to roll with the stock kernel and get it working properly with CM9 and then added in changes for the overclock and stuff later. Again since I am no kernel guru this is just my thought process.

The reason I am on the stance is because in all actuality there is not one kernel being used that is stock. I believe all kernel's TickerGuy, IssacJ, Mantera, Whyzor and b_randon's kernels are all from merged CAF source code. I know there is lots of issues with all those kernel's and deep sleep and Wifi but the stock kernel deep sleep works fine with Wifi. I propose that if you can upgrade the 100% stock kernel everything should work properly as a lot of the hardware issues have been resolved in the code, and or can be fixed through the code.

The kernel is the spinal cord of the whole OS which I know you know. So in fixing that everything else should come together in my logic. Of course no one ever said my logic is sound :rolleyes:

What was dorragaray final comments on this. Has he said he has done all he can or is he just too busy to be bothered. Curious to see if he has any idea on what wouldbstill have to be dealt with.
 
Ok, I didn't realize deep sleep worked with wifi in the stock kernel, that is quite interesting. It makes me think your idea of going back to the stock might be a good move.

What would be involved in upgrading the stock kernel? Just updating the camera portions, or are there some other pieces that need to be updated as well? Obviously there's the overclock stuff, but I just mean in terms of everything fundamentally working.
If you want, you can check out my github, I have a custom stock kernel that has everything already in it, plus updated touch screen drivers. It is the Sharp kernel, but it is our kernel source modified. I don't know what the differences in GB or ICS kernels from Froyo, but I know ueventd was added for GB. Hope this helps.
 
What would be involved in upgrading the stock kernel? Just updating the camera portions, or are there some other pieces that need to be updated as well? Obviously there's the overclock stuff, but I just mean in terms of everything fundamentally working.

This is where I am stuck I have not seen any documentation what is different from one kernel rev from Froyo to GB to ICS to JB. I am really not sure what it would take. I would assume updating specific settings for KGSL, PMEM and other features of the kernel are needed but I am not sure where to look for this info.

What was dorragaray final comments on this. Has he said he has done all he can or is he just too busy to be bothered. Curious to see if he has any idea on what wouldbstill have to be dealt with.

The problem right now with getting dorragaray involved with this project is there is just to many possible issues on what is wrong. I really truly believe all the code dorragaray gave us for the CameraHAL is complete and stable, I think the issues lies with in the kernel (I will state this till I am blue in the face :rolleyes:). dorragaray installed patches in our kernel to stop the ongoing SIGV error's. While this worked fine in his kernel it did not work in ours. I really believe that if we could upgrade our stock kernel it would solve all our issues. Sadly I don't know enough about kernels to solve this and I think if we had a kernel wiz or some one that understands the Android kernel source we might be able to solve the blasted camera.
 
If you want, you can check out my github, I have a custom stock kernel that has everything already in it, plus updated touch screen drivers. It is the Sharp kernel, but it is our kernel source modified. I don't know what the differences in GB or ICS kernels from Froyo, but I know ueventd was added for GB. Hope this helps.

What do you mean by sharp kernel, but our source modified?

EDIT:
Also, what is the status of cpu deep sleep and wifi on your kernel?
 
This is where I am stuck I have not seen any documentation what is different from one kernel rev from Froyo to GB to ICS to JB. I am really not sure what it would take. I would assume updating specific settings for KGSL, PMEM and other features of the kernel are needed but I am not sure where to look for this info.

Ok, I'll try to find out what the changes in these various kernel branches are. As a baseline, do we know that the stock kernel won't "just work"?
 
What do you mean by sharp kernel, but our source modified?

EDIT:
Also, what is the status of cpu deep sleep and wifi on your kernel?

I ported a couple ROMs from variants of our phone and long story short, I had to use our kernel (zimage) to get everything working, then I found some issues that led to the kernel and then learned how to mess with kernels and then built the kernel, I just called it the Sharp kernel cause it was built for the Sharp ROM, but for our phone from our kernel source.

The Sharp and U9000 ROMs both function as they should with outstanding battery, and proper wake locks, and they both use the same zimage.

Github:
https://github.com/BSydz/Triumph-Sharp-2.2.2-Custom-Kernel

Sharp ROM:
http://androidforums.com/triumph-al...harp-rom-2-2-2-triumph-updated-7-15-12-a.html
 
This is where I am stuck I have not seen any documentation what is different from one kernel rev from Froyo to GB to ICS to JB. I am really not sure what it would take. I would assume updating specific settings for KGSL, PMEM and other features of the kernel are needed but I am not sure where to look for this info.



The problem right now with getting dorragaray involved with this project is there is just to many possible issues on what is wrong. I really truly believe all the code dorragaray gave us for the CameraHAL is complete and stable, I think the issues lies with in the kernel (I will state this till I am blue in the face :rolleyes:). dorragaray installed patches in our kernel to stop the ongoing SIGV error's. While this worked fine in his kernel it did not work in ours. I really believe that if we could upgrade our stock kernel it would solve all our issues. Sadly I don't know enough about kernels to solve this and I think if we had a kernel wiz or some one that understands the Android kernel source we might be able to solve the blasted camera.

I believe the main thing you need to change to get a Froyo kernel to boot ICS is the BOOTCLASSPATH
 
Hey guys, I think only those who had a rooted Samsung Intercept will know this guy. Over at sdx there is this guy named Joseph Mother who did wonders for that crappy phone. I remember he would cook up kernels without even having the blasted phone. And, well, do you guys think if we contacted him he could help us out? Just a curious thought..
 
Hey guys, I think only those who had a rooted Samsung Intercept will know this guy. Over at sdx there is this guy named Joseph Mother who did wonders for that crappy phone. I remember he would cook up kernels without even having the blasted phone. And, well, do you guys think if we contacted him he could help us out? Just a curious thought..

Wouldn't hurt to ask. I don't know him but if you have an in ask and see, and send him the link to this post to see what he thinks.
 
I have gone back and forth rewriting this post with different information for the last 2 hours as I learn more. I think I've finally come full circle.

Found a difference in msm_camera.h in libcamera2/camerahal and the kernel. Got excited, but it looks like it isn't being used. It's in native_get_picture() in QualcommCameraHardware.cpp, and it probably won't work if anyone tries to use it :P

Then I took a closer look at your logcat, and saw the window is NULL message, and got excited again. But, I traced it back through the android source and it looks like that is what they do for QCOM_HARDWARE.

I don't know why I couldn't find some of your logcat messages yesterday, I see them all fine now. But, I realized that the data parameter of QualcommCameraHardware::runFrameThread() is really an msm_frame, which is where the difference is in msm_camera.h. So I'm back to where I was, this is certainly a problem. Here is the diff, I believe the kernel version is correct:

[HIGH]
diff -u ./hardware/qcom/libcamera2/msm_camera.h ./kernel/motorola/triumph/include/media/msm_camera.h
--- ./hardware/qcom/libcamera2/msm_camera.h 2012-11-26 19:35:09.714678299 -0700
+++ ./kernel/motorola/triumph/include/media/msm_camera.h 2012-11-26 19:35:22.370519193 -0700
@@ -584,8 +584,8 @@
int stcam_quality_ind;
uint32_t stcam_conv_value;

- struct ion_allocation_data * ion_alloc;
- struct ion_fd_data * fd_data;
+ struct ion_allocation_data ion_alloc;
+ struct ion_fd_data fd_data;
};
[/HIGH]
 
Wouldn't hurt to ask. I don't know him but if you have an in ask and see, and send him the link to this post to see what he thinks.

A wise man once said "what do you do when you are stuck? Ask some1 for help." We got the guy to patch camera, we need a kernel dev to finish it. I think a bounty would make a few people atleast take a look.

Btw, my buddies triumph died. He went with evo v for 150$. I don't have a triumph. Why am i still here?
 
I have gone back and forth rewriting this post with different information for the last 2 hours as I learn more. I think I've finally come full circle.

Found a difference in msm_camera.h in libcamera2/camerahal and the kernel. Got excited, but it looks like it isn't being used. It's in native_get_picture() in QualcommCameraHardware.cpp, and it probably won't work if anyone tries to use it :P

Then I took a closer look at your logcat, and saw the window is NULL message, and got excited again. But, I traced it back through the android source and it looks like that is what they do for QCOM_HARDWARE.

I don't know why I couldn't find some of your logcat messages yesterday, I see them all fine now. But, I realized that the data parameter of QualcommCameraHardware::runFrameThread() is really an msm_frame, which is where the difference is in msm_camera.h. So I'm back to where I was, this is certainly a problem. Here is the diff, I believe the kernel version is correct:

[HIGH]
diff -u ./hardware/qcom/libcamera2/msm_camera.h ./kernel/motorola/triumph/include/media/msm_camera.h
--- ./hardware/qcom/libcamera2/msm_camera.h 2012-11-26 19:35:09.714678299 -0700
+++ ./kernel/motorola/triumph/include/media/msm_camera.h 2012-11-26 19:35:22.370519193 -0700
@@ -584,8 +584,8 @@
int stcam_quality_ind;
uint32_t stcam_conv_value;

- struct ion_allocation_data * ion_alloc;
- struct ion_fd_data * fd_data;
+ struct ion_allocation_data ion_alloc;
+ struct ion_fd_data fd_data;
};
[/HIGH]

Do you want to me add this to the kernel on github? If need be we can have Chairshot give you access.

A wise man once said "what do you do when you are stuck? Ask some1 for help." We got the guy to patch camera, we need a kernel dev to finish it. I think a bounty would make a few people atleast take a look.

Btw, my buddies triumph died. He went with evo v for 150$. I don't have a triumph. Why am i still here?

Right now MTDEV has about $20.00 bucks in the paypal so don't have much of a bounty right now. Will see what becomes on this thread. Looks like it's moving in the right direction.
 
Back
Top Bottom