dsmryder
Android Expert
That's a question better answered by chairshot. I just know what leg work I have done. I think the libs come from the Sharp ROM. I'll see if I can find the commit. It's in the MTDEV-CM7 repo.
-
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]
- Thread starter g60madman
- Start date
-
- Tags
- motorola triumph
That's a question better answered by chairshot. I just know what leg work I have done. I think the libs come from the Sharp ROM. I'll see if I can find the commit. It's in the MTDEV-CM7 repo.
Thanks, that's what I was leaning toward, hence my info about the libs. I didn't set it up or have ownership to the MTCM9 github, nor would I have had the knowledge. A more complete answer is below...
As far as the htcoverlay and the regular overlay, it has to do with the gralloc, and how the camera and if we build it with the system, all display stuff works together, I think. In our board config file it has BOARD_USES_OVERLAY which is as flag in hardware/qcom/display, which is spelled wrong in the board config in the repository. the Overlay files should be located in frameworks/base/lib/ui/Overlay.cpp and frameworks/base/include/ui/Overlay.h, but it is not included in the source. Like I said, I am not sure myself. The camerhal folder has the two Overlay files and both folders have files with includes for htcOverlay.h in include/ui. Don't really know what I'm saying here, but just what I have seen.
OK, I just looked and the HP Touchpad runs the 2.6.35.? kernel, so that makes sense that the lib only works with the 2.6.35.7 kernel cam files. Dorrey is the one who got the camera working on the TP, and he wrote the code for the cameraHal and libcamera2, and once G60 pointed me to a booting 2.6.35.7 kernel, I found that the camera worked(like it does now), but the kernel reboots every minute or two like clockwork. So I took all the camera stuff from that kernel and put it in to the kernel that was currently being used. Now, as for the libcameras, I had no part of setting that up, that is just the way it was. I am pretty sure that the libcamera.so is a prebuilt, but from which ROM, I have no idea. I just compared the files and it is not the Sharp 2.3.5 files, or the Cherry Magnum. You know what, I just compared them to all the variants even stock and they do not match. I have no idea where they came from.
EDIT: It does seem that most of the files in vendor/proprietary are from the Cherry magnum ROM except liba2dp, libaudio, libcamera, libdiag, liboemcamera, 7 libomx files, and the 3 ril files, as far as .so files.
adamto
Well-Known Member
Upon closer inspection, it is actually failing quite a bit earlier:
V/QualcommCameraHardware( 131): Calling CAMERA_START_VIDEO
I/QualcommCameraHardware( 131): native_start_video : E
D/QualcommCameraHardware( 131): frame_thread E
V/QualcommCameraHardware( 131): getInstance E
V/QualcommCameraHardware( 131): runFrameThread E
V/QualcommCameraHardware( 131): runFrameThread, libmmcamera: 0x7000f050
V/QualcommCameraHardware( 131): before LINK_cam_frame, data: 0x2ba2b104
And the frame thread hangs there, presumably causing the later errors.
dsmryder
Android Expert
I bet that's why the camera orientation is wrong. If you feel froggy, try it with Action Snap. Or panarama. Both of those have the proper orientation.
What's up guys? I have some info and some questions.
First, my questions.
So our basic goal is to get liboemcamera.so to work with our QualcommCameraHardware files, correct?
If we are using the 2.6.35.7 kernel camera files, should we be using the Sharp 2.3.5 camera drivers? One issue is that all of our Variants except the Sharp 2.3.5 us 2GVMSPLIT and 2.3.5 uses 3GVMSPLIT. After doing some research, it seems that using files from a 3G split can cause issues when used with a 2G split kernel and system. Issues involve, if I remember correctly, restarts, random crashes and other odd tidbits, caused by the way the driver calls memory. On a side note, while looking through isaac's commits, when he was working on MIUI he was running the kernel as 3GVMSPLIT cause the system he ported from was built using 3G split. That makes me wonder why we haven't been building our kernel and system that way.
Info: There is a line in device/motorola/triumph/BoardConfig.mk and in our kernel triumph_defconfig, for the VMSPLIT.
We have four choices of camera setups for the kernel, as far as actual driver files and setups in the board.7x30 file, 2.6.35.7, M410, Stock & U8850. I know we have to keep all the generic kernel stuff from 2.6.35.7, for the code we have now, but I have the same results with any of the driver files. I have been using the drivers from the U8850 kernel, the differences are fairly subtle, but it uses a full scan auto focus, that was added after the M410 kernel was released.
Between the 2.6.35.7 kernel and our old kernel there are quuite a few differences:
When I use the kernel that I updated all the camera stuff from 3.0.8, the cameras load fine, according to dmesg, but I get segfaults with QualcommCameraHardware like before the 2.6.35.7 updates. So this also leads me to the QualcommCameraHardware files.
For any files that you may want to look at from the X6 variants, you can find them here http://androidforums.com/triumph-all-things-root/655402-dev-bsydz-triumph-x6-port-encylopedia.html
I just wanted to get this info out there, as I hope it is useful. I wish I knew more about the code and how it all works together, I am becoming more familiar but I'm not quite there yet. Sorry for the rambling, I have so much stuff running around my skull and don't quite understand some of it. So feel free to ask any questions you might have, I've been all through the code am familiar with most of it. Also, any info is always appreciated.
First, my questions.
So our basic goal is to get liboemcamera.so to work with our QualcommCameraHardware files, correct?
If we are using the 2.6.35.7 kernel camera files, should we be using the Sharp 2.3.5 camera drivers? One issue is that all of our Variants except the Sharp 2.3.5 us 2GVMSPLIT and 2.3.5 uses 3GVMSPLIT. After doing some research, it seems that using files from a 3G split can cause issues when used with a 2G split kernel and system. Issues involve, if I remember correctly, restarts, random crashes and other odd tidbits, caused by the way the driver calls memory. On a side note, while looking through isaac's commits, when he was working on MIUI he was running the kernel as 3GVMSPLIT cause the system he ported from was built using 3G split. That makes me wonder why we haven't been building our kernel and system that way.
Info: There is a line in device/motorola/triumph/BoardConfig.mk and in our kernel triumph_defconfig, for the VMSPLIT.
We have four choices of camera setups for the kernel, as far as actual driver files and setups in the board.7x30 file, 2.6.35.7, M410, Stock & U8850. I know we have to keep all the generic kernel stuff from 2.6.35.7, for the code we have now, but I have the same results with any of the driver files. I have been using the drivers from the U8850 kernel, the differences are fairly subtle, but it uses a full scan auto focus, that was added after the M410 kernel was released.
Between the 2.6.35.7 kernel and our old kernel there are quuite a few differences:
mt9p111.c:
[HIGH]CAMERA_BRIGHTNESS_0 (2.6.35.7, M410, Stock & U8850)
CAMERA_BRIGHTNESS_LV0 (MTCM9 2.6.32.59)
[/HIGH]
[HIGH]CAMERA_CONTRAST_MINUS2 (2.6.35.7, M410, Stock & U8850)
CAMERA_CONTRAST_LV1 (MTCM9 2.6.32.59)
[/HIGH]
And the list goes on but this is getting disorganized fast.
These two lines are what is needed to actually make the camera interact, as far as I can tell from my tests, I was testing the different drivers and forgot to edit this and the camera failed.
[HIGH] s->s_mount_angle = 0;
[/HIGH]and this being commented out and moved from the middle of the file to the end
[HIGH] sensor_init_parameters(info,&mt9p111_parameters);
[/HIGH]
[HIGH]CAMERA_BRIGHTNESS_0 (2.6.35.7, M410, Stock & U8850)
CAMERA_BRIGHTNESS_LV0 (MTCM9 2.6.32.59)
[/HIGH]
[HIGH]CAMERA_CONTRAST_MINUS2 (2.6.35.7, M410, Stock & U8850)
CAMERA_CONTRAST_LV1 (MTCM9 2.6.32.59)
[/HIGH]
And the list goes on but this is getting disorganized fast.
These two lines are what is needed to actually make the camera interact, as far as I can tell from my tests, I was testing the different drivers and forgot to edit this and the camera failed.
[HIGH] s->s_mount_angle = 0;
[/HIGH]and this being commented out and moved from the middle of the file to the end
[HIGH] sensor_init_parameters(info,&mt9p111_parameters);
[/HIGH]
When I use the kernel that I updated all the camera stuff from 3.0.8, the cameras load fine, according to dmesg, but I get segfaults with QualcommCameraHardware like before the 2.6.35.7 updates. So this also leads me to the QualcommCameraHardware files.
For any files that you may want to look at from the X6 variants, you can find them here http://androidforums.com/triumph-all-things-root/655402-dev-bsydz-triumph-x6-port-encylopedia.html
I just wanted to get this info out there, as I hope it is useful. I wish I knew more about the code and how it all works together, I am becoming more familiar but I'm not quite there yet. Sorry for the rambling, I have so much stuff running around my skull and don't quite understand some of it. So feel free to ask any questions you might have, I've been all through the code am familiar with most of it. Also, any info is always appreciated.
dsmryder
Android Expert
When I get home I'll see where the camera libraries I copied over came from. I'm pretty sure I know it's in the CM7 thread just a couple of pages back.
adamto
Well-Known Member
This is exactly the sort of thing I wanted to track down, thanks a bunch. I'll take a closer look after work.
OK, so after pulling the strings from the Sharp 2.3.5 liboemcamera.so, and comparing it to the Cherry liboemcamera.so, it looks like alot of the differences between kernel files is showing up. I think we need to see if the files from the Sharp 2.3.5 work, I'll throw them in and test them out, but it makes it a little clearer also what needs to be changed in the cameraHal. Good luck everybody.
dsmryder
Android Expert
From a "github" sort of way, it may be wise to have a running set of folders with the blobs organized as nessacery.
i.e. Sharp_camera, stock_media...
dsmryder
Android Expert
OK guys, I have pused up the .so files from some of the varients. They are now a part of the vendor tree under my branch. I haven't done any dependancy research yet, and won't even try until this week end. This will get you started and I hope will remove some confusion as to where the files came from. I haven't found the Cherry Mobile Magnum files yet. I'm going to try for tomorrow. As well the other varients.
This is the commit that I think I found the overlay files from or they were in a old CM9 I had on disk, https://github.com/mantera/android_frameworks_base/commit/fddc476754423c00b537e411f5f007d765f5872b
This is some info about some camera changes made in frameworks. On a side note, I am not using our frameworks base for PA, I only incorporated the ril, headset and one or two other small fixes. https://github.com/mantera/android_frameworks_base/commit/2bf9844dae4d70dab052ef426d010a4bd7a107cd
So while messing with some camera apps, I found "Camera Mod for Xperia PLAY" and while it doesn't take pics it does show the orientation correctly and it switches orientation when you switch cameras, even though it doesn't switch. It also gives some different errors to look at.
It also shows no options for flash and what not when on the back camera, but when you switch to front camera it has the wrong orientation but options for flash. This leads me to believe that the cameras are loading backwards. And also the front cam settings aren't being applied, the back camera settings are being applied to the front camera. This may be due to the back camera loading as the front camera, but you would think that the settings would be swapped and one would be the front cam settings.
So how do we get the proper camera to be loaded? I know there is a flag for front facing camera first or something similar, but I have had that enabled in a few builds and it never seemed to do anything.
It also shows no options for flash and what not when on the back camera, but when you switch to front camera it has the wrong orientation but options for flash. This leads me to believe that the cameras are loading backwards. And also the front cam settings aren't being applied, the back camera settings are being applied to the front camera. This may be due to the back camera loading as the front camera, but you would think that the settings would be swapped and one would be the front cam settings.
So how do we get the proper camera to be loaded? I know there is a flag for front facing camera first or something similar, but I have had that enabled in a few builds and it never seemed to do anything.
rukin5197
Android Enthusiast
I do know that tjstyle has got issues with FFC orientation on the Huawei Ideos X6 (our brother device). This kind of proves this point
RolaAddict
Android Enthusiast
Well that explains why the resolution for the camera is so poor.Would there be something in the cameraHAL code that would fix that?I have no clue on how to do any DEV stuff but it would seem that if the cameras are loading backwards it would have to be in the code right?
dsmryder
Android Expert
Yeah, I would think it would be in the kernel as that detects the devices first. I know action snap has things better. I think the camera that it opens to is correct. If I remember correctly it show a resolution that's 5M and down from there.
That was my point, both cameras show 5MP but only one will allow flash and more advanced options.The kernel is working properly, the kernel logs are identical to the Cherry ROM. The driver was written for the HP Touchpad and there are lines in the cameraHal like "/*Disable auto focus on touchpad */" and others. I see lines added for 5mp_triumph in QualcommCameraHardware.cpp, those are the lines in the log that say "blah is not supported by this sensor". There are also lines like "Don't know the AEC_ROI_* values " in setTouchAFAec, followed by TouchAFAec is not supported by this sensor. Makes me wonder if it is or not, like was the line put there just to get by.
Here are the HP cam specs:
Camera Primary 1.3 MP, 1280 x 1024 pixels
Features Video-calling
Video No
Secondary No
So, I guess one of us needs to get in contact with Dorrey, and figure out what flags we need to have set in the boardconfig to use both cameras, if there are any.
RolaAddict
Android Enthusiast
I would do it if I knew the guy.
dsmryder
Android Expert
Going by what you said. I am looking at the board configuration for CM7 and CM9. CM7 uses
Code:
BOARD_CAMERA_USE_GETBUFFERINFO := true
Code:
BOARD_USES_HTC_CAMERA := trueI just finished an experimental build that flashes the flash and shows the saved picture and then errors out at the jpeg encoder. It only shows having one camera, but it is getting somewhere. It also fixes rotation after switching picture quality, but is mirrored. Panorama doesn't work either. Now I just need to figure out what helped and what didn't.
I figure I will post it if some people want to tinker and check out other apps and stuff.
pa_triumph-1.6a-16FEB2013-Cam-Experiment
I figure I will post it if some people want to tinker and check out other apps and stuff.
pa_triumph-1.6a-16FEB2013-Cam-Experiment
dsmryder
Android Expert
I gave the line a swap and it stopped the build. And it seem that you may be on to something anyway. I'm tryng something else before I go to bed.
I don't know why it would stop the build, I had htc commented out and get buffer added in. But I also had the overlay from mantera in the frameworks. I just pushed my device files for PA, check out the BoardConfig in the Experimental branch.
mozzwald
Newbie
I removed the HTC line and it still compiled over here.
While poking around in cameraHALL.cpp I see a few references to "BOARD_USE_FROYO_LIBCAMERA". We are using the libcamera from Froyo, correct? Maybe enabling this will help.
[HIGH]#if defined(BOARD_USE_FROYO_LIBCAMERA)
#ifndef FIRST_CAMERA_FACING
#define FIRST_CAMERA_FACING CAMERA_FACING_BACK
#endif
#ifndef FIRST_CAMERA_ORIENTATION
#define FIRST_CAMERA_ORIENTATION 90
#endif
static const CameraInfo sCameraInfo[] = {
{
FIRST_CAMERA_FACING,
FIRST_CAMERA_ORIENTATION, /* orientation */
1, /* CAMERA_MODE_2D */
},
{
CAMERA_FACING_FRONT,
270, /* orientation */
1, /* CAMERA_MODE_2D */
}
};
#endif[/HIGH]