This is completely out of topic but I would appreciate if someone could help me.
I dropped and broke my Triumph so I'm getting a replacement one, and I was wondering if the nandroid backups I've made so far are going to work with the new phone? Also if I would need to restore the phone back to the "original stock VM rom" and stock recovery.
Thanks for all the help in advance guys.
Device(s): HTC Evo V 4G [HTCDEV CM10]
Motorola Triumph [MTDEV CM9]
Carrier: Virgin Mobile
Thanks: 10
Thanked 1 Time in 1 Post
Quote:
Originally Posted by homeboy97
This is completely out of topic but I would appreciate if someone could help me.
I dropped and broke my Triumph so I'm getting a replacement one, and I was wondering if the nandroid backups I've made so far are going to work with the new phone? Also if I would need to restore the phone back to the "original stock VM rom" and stock recovery.
Thanks for all the help in advance guys.
Sorry about the phone. Restoring your previous backups to your replacement should work fine, as long as you still have those backups. Same exact phone and hardware. There may be some conflicts, such as having a different serial number and things like that.
Not sure I understand your second question.
This is completely out of topic but I would appreciate if someone could help me.
I dropped and broke my Triumph so I'm getting a replacement one, and I was wondering if the nandroid backups I've made so far are going to work with the new phone? Also if I would need to restore the phone back to the "original stock VM rom" and stock recovery.
Thanks for all the help in advance guys.
Backups should work fine I think, and VM doesn't care about the stock image on the original phone. If you want to and are able to, it doesn't hurt to do it.
Sorry about the phone. Restoring your previous backups to your replacement should work fine, as long as you still have those backups. Same exact phone and hardware. There may be some conflicts, such as having a different serial number and things like that.
Not sure I understand your second question.
Quote:
Originally Posted by shiv81
Backups should work fine I think, and VM doesn't care about the stock image on the original phone. If you want to and are able to, it doesn't hurt to do it.
Thanks guys you answered all my questions I appreciate it! You guys rock!
ZipLip, there haven't been many updates lately on the camera because MikeRL is sick with (and correct me if I'm wrong) bronchitis. Or maybe the Lupus. I don't know.
There haven't been any updates because I am stupid busy and the heavy hitters have left for the Evo V. I have been trying to learn how to make Android apps so I can maybe build and correctostuff as things arise.
Like I said, I'm stupid busy (emphisis on the stupid part) with life, work and family. I wanted to spit out some ROMs to get them out there, but I don't just want to put out what is already out there without making some kind of usefull change.
Watch out for what BSydz and Rukin are doing as they have been rocking some code for JB.
Look at the main thread. This was a DEV thread. The new release is a minor update so I could practice the things I have to do when I make a more worthy release.
I installed CM9 to check out the camera status. Did some poking around and it seems that the camera may be crapping out at auto-focus. You can leave camera open all day and it will work fine, but when you click the button to take a picture the first thing to pop up in logcat is:
The camera continues to display to the screen then you get the ANR dialog and some more info in logcat. If you force close the camera continues to run in the background. When starting the camera app I see "E/QualcommCameraHardware( 131): AutoFocus is not supported" in logcat which could be why it's timing out during focus even though the camera does support autofocus.
The video orientation is not rotated correctly in the camera app. During startup you can see both cameras detected and one has "orientation=180". If I'm not mistaken cam ID 0 is the rear and cam ID 1 is the front. Can you make the rear camera rotate correctly or am I not identifying these correctly?
I installed CM9 to check out the camera status. Did some poking around and it seems that the camera may be crapping out at auto-focus. You can leave camera open all day and it will work fine, but when you click the button to take a picture the first thing to pop up in logcat is:
The camera continues to display to the screen then you get the ANR dialog and some more info in logcat. If you force close the camera continues to run in the background. When starting the camera app I see "E/QualcommCameraHardware( 131): AutoFocus is not supported" in logcat which could be why it's timing out during focus even though the camera does support autofocus.
The video orientation is not rotated correctly in the camera app. During startup you can see both cameras detected and one has "orientation=180". If I'm not mistaken cam ID 0 is the rear and cam ID 1 is the front. Can you make the rear camera rotate correctly or am I not identifying these correctly?
On a side note, is there an mtdev irc channel? I'm always on freenode and would be nice to toss ideas in a live environment instead of a forum.
I've always wanted to join an MTDEV irc channel, as I am frequently on freenode as well. Unfortunately when I talked to G60 he said that he could not start one because his work blocks IRC communications and his phone didn't get good enough reception to use AndChat. Some of the best dev work I've done came form bouncing ideas in an IRC chatroom. If you want to start one, that would be cool. I can't promise I'd be on it 24/7 but I would definitely frequent it.
I installed CM9 to check out the camera status. Did some poking around and it seems that the camera may be crapping out at auto-focus. You can leave camera open all day and it will work fine, but when you click the button to take a picture the first thing to pop up in logcat is:
The camera continues to display to the screen then you get the ANR dialog and some more info in logcat. If you force close the camera continues to run in the background. When starting the camera app I see "E/QualcommCameraHardware( 131): AutoFocus is not supported" in logcat which could be why it's timing out during focus even though the camera does support autofocus.
The video orientation is not rotated correctly in the camera app. During startup you can see both cameras detected and one has "orientation=180". If I'm not mistaken cam ID 0 is the rear and cam ID 1 is the front. Can you make the rear camera rotate correctly or am I not identifying these correctly?
On a side note, is there an mtdev irc channel? I'm always on freenode and would be nice to toss ideas in a live environment instead of a forum.
Yeah, and it craps out after the focus too. I remade the camera app with the focus commented out and got a click.
Since then I haven't had time to look at anything. Not like ir really know what I'm doing. (I do appreciate the encouragement guys). If you entry, I can tell you what little I do know. PM me
Yeah, and it craps out after the focus too. I remade the camera app with the focus commented out and got a click.
Since then I haven't had time to look at anything. Not like ir really know what I'm doing. (I do appreciate the encouragement guys). If you entry, I can tell you what little I do know. PM me
It seems to stop when the autofocus call is sent to the camera. Do you have your remade camera app somewhere for download? I still haven't setup a build environment yet (other than kernel).
Quote:
Originally Posted by jhonka232
I've always wanted to join an MTDEV irc channel, as I am frequently on freenode as well. Unfortunately when I talked to G60 he said that he could not start one because his work blocks IRC communications and his phone didn't get good enough reception to use AndChat. Some of the best dev work I've done came form bouncing ideas in an IRC chatroom. If you want to start one, that would be cool. I can't promise I'd be on it 24/7 but I would definitely frequent it.
I jumped into an empty #mtdev channel on irc.freenode.net if anyone wants to join. There's a logbot there so you can read what happened while your gone (irc.freenode.net logfiles - www.mozzwald.com). Not sure if it works behind a firewall but there is a webchat for irc at freenode Web IRC (qwebirc)
To get around my firewall at work I ssh to my home linux server and always have irssi running.
It seems to stop when the autofocus call is sent to the camera. Do you have your remade camera app somewhere for download? I still haven't setup a build environment yet (other than kernel).
I jumped into an empty #mtdev channel on irc.freenode.net if anyone wants to join. There's a logbot there so you can read what happened while your gone (irc.freenode.net logfiles - www.mozzwald.com). Not sure if it works behind a firewall but there is a webchat for irc at freenode Web IRC (qwebirc)
To get around my firewall at work I ssh to my home linux server and always have irssi running.
If I have the app still I'll post it for you. I didn't commit the change as I just wanted to do the one thing. As far as IRC, I haven't done one before LOL I would have to look it up,
I installed CM9 to check out the camera status. Did some poking around and it seems that the camera may be crapping out at auto-focus. You can leave camera open all day and it will work fine, but when you click the button to take a picture the first thing to pop up in logcat is:
Auto focus was disabled at QualcommCameraHardware.cpp:759 (that false is an auto focus bool). I turned this on, and it's getting a bit further, still failing. It's getting into takePicture(), but is getting receive_camframe_error_timeout, which is coming from the blob.
The Following 3 Users Say Thank You to adamto For This Useful Post:
Auto focus was disabled at QualcommCameraHardware.cpp:759 (that false is an auto focus bool). I turned this on, and it's getting a bit further, still failing. It's getting into takePicture(), but is getting receive_camframe_error_timeout, which is coming from the blob.
Tested this out tonight. It does try to autofocus (I can hear the camera focusing) then it will sit indefinitely until you touch the screen then it prompts to close the camera app. I previously tested dsmryder's camera.apk with focusing disabled and it would at least flash before trying to take picture. I made sure to turn on flash with this test and it does not flash after/during focusing.
The Following User Says Thank You to mozzwald For This Useful Post:
Auto focus was disabled at QualcommCameraHardware.cpp:759 (that false is an auto focus bool). I turned this on, and it's getting a bit further, still failing. It's getting into takePicture(), but is getting receive_camframe_error_timeout, which is coming from the blob.
Thanks guys. If I knew more about this I would have probably have seen this easily, sounds like you did. If there is anything I can do for you, let me know.
Auto focus was disabled at QualcommCameraHardware.cpp:759 (that false is an auto focus bool). I turned this on, and it's getting a bit further, still failing. It's getting into takePicture(), but is getting receive_camframe_error_timeout, which is coming from the blob.
What are you talking about when you say "the blob"?
Quote:
Originally Posted by mozzwald
Tested this out tonight. It does try to autofocus (I can hear the camera focusing) then it will sit indefinitely until you touch the screen then it prompts to close the camera app. I previously tested dsmryder's camera.apk with focusing disabled and it would at least flash before trying to take picture. I made sure to turn on flash with this test and it does not flash after/during focusing.
So are you guys, building the ROM or just the module? If you are building the ROM, you need to delete the libcamera.so and rename licamera2.so to libcamera.so. You will also want to put any changes from camerhal in to libcamera2, that is the libcamera2.so we build.
One thing I was working on was getting away from the htcoverlay and using a proper overlay.cpp and .h, but now for the life of me I can't figure out where I got the overlay files from, I think it was mantera. But when I use that overlay, the cameraHal has errors about being able to dequeue the buffer, but works just like with the htcoverlay.
Gotta go, just thought I would throw those couple things out there.
__________________ "If somethings in your way, you gotta move it or use it." - Me
If you would like to thank me, beyond just saying thanks, you can donate to my coffee fund to keep my eyes open. Donate
The Following User Says Thank You to BSydz For This Useful Post:
What are you talking about when you say "the blob"?
A 'blob' is the proprietary precompiled drivers that interface with the hardware and is provided by the manufacturer.
Quote:
Originally Posted by BSydz
So are you guys, building the ROM or just the module? If you are building the ROM, you need to delete the libcamera.so and rename licamera2.so to libcamera.so. You will also want to put any changes from camerhal in to libcamera2, that is the libcamera2.so we build.
I didn't know that needed to be done. Why don't we just replace libcamera sources with libcamera2? Or were you just trying to keep things separate until we find what works?
I notice now that there's several places where QualcommCameraHardware.cpp exists (hardware/qcom/camerahal, hardware/qcom/libcamera2, hardware/msm7k/libcamera) and there are some differences b/w the files. Are these all being built and used? Can we just symlink the files so there's only one copy that needs to be modified? Not sure if the compiler will complain about that.
The Following User Says Thank You to mozzwald For This Useful Post:
A 'blob' is the proprietary precompiled drivers that interface with the hardware and is provided by the manufacturer.
I didn't know that needed to be done. Why don't we just replace libcamera sources with libcamera2? Or were you just trying to keep things separate until we find what works?
I notice now that there's several places where QualcommCameraHardware.cpp exists (hardware/qcom/camerahal, hardware/qcom/libcamera2, hardware/msm7k/libcamera) and there are some differences b/w the files. Are these all being built and used? Can we just symlink the files so there's only one copy that needs to be modified? Not sure if the compiler will complain about that.
Unless someone tells me not to, I'll make sure the libraries are the set wee used in CM7. I have already checked their dependencies so i know they are complete.
The Following User Says Thank You to dsmryder For This Useful Post:
What are you talking about when you say "the blob"?
So are you guys, building the ROM or just the module? If you are building the ROM, you need to delete the libcamera.so and rename licamera2.so to libcamera.so. You will also want to put any changes from camerhal in to libcamera2, that is the libcamera2.so we build.
One thing I was working on was getting away from the htcoverlay and using a proper overlay.cpp and .h, but now for the life of me I can't figure out where I got the overlay files from, I think it was mantera. But when I use that overlay, the cameraHal has errors about being able to dequeue the buffer, but works just like with the htcoverlay.
Gotta go, just thought I would throw those couple things out there.
mozzwald is right, in our case the blob is liboemcamera.so. You will see in QualcommCameraHardware, this library is dlopen()ed and these LINK_* functions are the blob interface. I was trying to track this down a little bit, but couldn't figure this out: where did our liboemcamera.so come from? It may be important that it is in sync with the kernel camera code and QualcommCameraHardware. Do you know if what we have checked in for these three pieces is from the same place?
Ah I was wondering about libcamera.so/libcamera2.so. I was going to try the other one but ran out of time last night.
Hmm, don't know much about overlays yet. Is there a problem with the htcoverlay?
The Following User Says Thank You to adamto For This Useful Post:
Unless someone tells me not to, I'll make sure the libraries are the set wee used in CM7. I have already checked their dependencies so i know they are complete.
Just to make sure I understand, the cm9 kernel now has the original motorola camera code? If so, that makes sense, and also please check liboemcamera.so.
I've tried both libcamera and libcamera2, tried the cm9, cm7, and stock liboemcamera.so. Same results with all. QualcommCameraHardware enters native_stop_video() and is getting hung up there (the ioctl is failing):
V/QualcommCameraHardware( 131): enableMsgType E
V/QualcommCameraHardware( 131): takePicture(463)
I/QualcommCameraHardware( 131): stopPreviewInternal E: 1
V/QualcommCameraHardware( 131): cancelAutoFocusInternal E
V/QualcommCameraHardware( 131): cancelAutoFocusInternal X: not in progress
V/QualcommCameraHardware( 131): in native_stop_video I/QualcommCameraHardware( 131): native_stop_video: E
D/AudioHardwareMSM7X30( 131): msm_route_stream(PCM_PLAY,5,8,1)
D/AudioHardwareMSM7X30( 131): AudioStreamOutMSM72xx::standby()
D/AudioHardwareMSM7X30( 131): Deroute pcm out stream
E/AudioHardwareMSM7X30( 131): updateDeviceInfo: E rx_device 6 and tx_device 11
D/AudioHardwareMSM7X30( 131): No active voicecall/playback, disabling cur_rx 6
D/AudioHardwareMSM7X30( 131): value of device and enable is 6 0 ALSA dev id:8
D/AudioHardwareMSM7X30( 131): No active voicecall/recording, disabling cur_tx 11
D/AudioHardwareMSM7X30( 131): value of device and enable is 11 0 ALSA dev id:17
E/AudioHardwareMSM7X30( 131): updateDeviceInfo: X cur_rx 6 cur_tx 11
I/InputDispatcher( 234): Application is not responding: Window{2bc388c0 com.android.camera/com.android.camera.Camera paused=false}. 5017.0ms since event, 5009.7ms since wait started
I/Process ( 234): Sending signal. PID: 760 SIG: 3
I/dalvikvm( 760): threadid=3: reacting to signal 3
I/dalvikvm( 760): Wrote stack traces to '/data/anr/traces.txt'
I/Process ( 234): Sending signal. PID: 234 SIG: 3
I/dalvikvm( 234): threadid=3: reacting to signal 3
I/dalvikvm( 234): Wrote stack traces to '/data/anr/traces.txt'
I/Process ( 234): Sending signal. PID: 315 SIG: 3
I/dalvikvm( 315): threadid=3: reacting to signal 3
I/dalvikvm( 315): Wrote stack traces to '/data/anr/traces.txt'
I/Process ( 234): Sending signal. PID: 390 SIG: 3
I/dalvikvm( 390): threadid=3: reacting to signal 3
I/dalvikvm( 390): Wrote stack traces to '/data/anr/traces.txt'
I/dalvikvm( 234): Jit: resizing JitTable from 4096 to 8192
D/dalvikvm( 234): GC_EXPLICIT freed 1589K, 40% free 4640K/7623K, paused 3ms+5ms
V/QualcommCameraHardware( 131): getInstance E
I/QualcommCameraHardware( 131): receive_camframe_error_timeout: E
I/Process ( 234): Sending signal. PID: 358 SIG: 3
I/dalvikvm( 358): threadid=3: reacting to signal 3
I/dalvikvm( 358): Wrote stack traces to '/data/anr/traces.txt'
E/ActivityManager( 234): ANR in com.android.camera (com.android.camera/.Camera)
E/ActivityManager( 234): Reason: keyDispatchingTimedOut
E/ActivityManager( 234): Load: 10.07 / 3.5 / 1.25
E/ActivityManager( 234): CPU usage from 9160ms to 3170ms ago:
E/ActivityManager( 234): 9.1% 358/android.process.media: 6.5% user + 2.6% kernel / faults: 65 minor
E/ActivityManager( 234): 2.6% 131/mediaserver: 1.5% user + 1.1% kernel / faults: 39 minor
E/ActivityManager( 234): 2.5% 128/surfaceflinger: 1.3% user + 1.1% kernel / faults: 3 minor
E/ActivityManager( 234): 1.6% 234/system_server: 1.5% user + 0.1% kernel / faults: 22 minor
E/ActivityManager( 234): 1.5% 760/com.android.camera: 1.1% user + 0.3% kernel / faults: 264 minor
E/ActivityManager( 234): 1.1% 102/mmcqd: 0% user + 1.1% kernel
E/ActivityManager( 234): 1.1% 154/adbd: 0.1% user + 1% kernel
E/ActivityManager( 234): 0.6% 16/kinteractiveup: 0% user + 0.6% kernel
E/ActivityManager( 234): 0.6% 17/knteractive_dow: 0.6% user + 0% kernel
E/ActivityManager( 234): 0.6% 745/logcat: 0.3% user + 0.3% kernel
E/ActivityManager( 234): 0.5% 52/kgsl-3d0/0: 0% user + 0.5% kernel
E/ActivityManager( 234): 0.5% 96/mmcqd: 0% user + 0.5% kernel
E/ActivityManager( 234): 0.5% 749/logcat: 0.1% user + 0.3% kernel
E/ActivityManager( 234): 0.1% 4/events/0: 0% user + 0.1% kernel
E/ActivityManager( 234): 0% 93/acdb_cb_thread: 0% user + 0% kernel
E/ActivityManager( 234): 0% 127/rild: 0% user + 0% kernel
E/ActivityManager( 234): 0% 315/com.android.systemui: 0% user + 0% kernel / faults: 14 minor
E/ActivityManager( 234): 0% 390/com.android.phone: 0% user + 0% kernel / faults: 16 minor
E/ActivityManager( 234): 98% TOTAL: 12% user + 8.6% kernel + 77% iowait
E/ActivityManager( 234): CPU usage from 528ms to 1045ms later:
E/ActivityManager( 234): 5.8% 358/android.process.media: 2.9% user + 2.9% kernel / faults: 4 minor
E/ActivityManager( 234): 5.8% 722/MediaScannerSer: 2.9% user + 2.9% kernel
E/ActivityManager( 234): 5.6% 234/system_server: 1.8% user + 3.7% kernel
E/ActivityManager( 234): 3.7% 268/InputDispatcher: 1.8% user + 1.8% kernel
E/ActivityManager( 234): 100% TOTAL: 7.6% user + 5.7% kernel + 86% iowait
D/dalvikvm( 234): GC_FOR_ALLOC freed 755K, 40% free 4632K/7623K, paused 42ms
I/dalvikvm-heap( 234): Grow heap (frag case) to 13.182MB for 635812-byte allocation
I/Adreno200-EGLSUB( 128): <CreateImage:893>: Android Image
I/Adreno200-EGLSUB( 128): <GetImageAttributes:1102>: RGBA_8888
I/Adreno200-EGLSUB( 128): <CreateImage:893>: Android Image
I/Adreno200-EGLSUB( 128): <GetImageAttributes:1102>: RGBA_8888
I/InputDispatcher( 234): Dropped event because the current application is not responding and the user has started interacting with a different application.
W/ActivityManager( 234): Force finishing activity com.android.camera/.Camera
D/AudioHardwareMSM7X30( 131): value of device and enable is 6 1 ALSA dev id:8
I/ActivityManager( 234): Killing ProcessRecord{2bc2e2e8 760:com.android.camera/10007}: user's request
W/AudioFlinger( 131): session id 9 not found for pid 131
I/WindowManager( 234): WIN DEATH: Window{2bc388c0 com.android.camera/com.android.camera.Camera paused=true}
I/ActivityManager( 234): Process com.android.camera (pid 760) has died.
I/WindowManager( 234): WIN DEATH: Window{2bc39a58 SurfaceView paused=false}
I/Adreno200-EGLSUB( 410): <ConfigWindowMatch:2078>: Format RGBA_8888.
D/AudioHardwareMSM7X30( 131): msm_route_stream(PCM_PLAY,5,8,1)
W/InputManagerService( 234): Got RemoteException sending setActive(false) notification to pid 760 uid 10007
I/Adreno200-EGLSUB( 128): <CreateImage:893>: Android Image
I/Adreno200-EGLSUB( 128): <GetImageAttributes:1102>: RGBA_8888 E/QualcommCameraHardware( 131): native_stop_video: ioctl failed. ioctl return value is -1
E/QualcommCameraHardware( 131): stopPreviewInternal: failed to stop preview
I/QualcommCameraHardware( 131): stopPreviewInternal X: 1
V/QualcommCameraHardware( 131): mSnapshotFormat = PICTURE_FORMAT_JPEG
V/QualcommCameraHardware( 131): initRaw E
V/QualcommCameraHardware( 131): initRaw E: picture size=2592x1944
V/QualcommCameraHardware( 131): Thumbnail Size Width 320 Height 240
V/QualcommCameraHardware( 131): native_set_parm: fd 27, type 1, length 88
E/QualcommCameraHardware( 131): Camframe timed out. Not receiving any frames from camera driver
V/QualcommCameraHardware( 131): initRaw, jpeg_rotation = 0
V/QualcommCameraHardware( 131): initRaw: yOffset = 0, mCbCrOffsetRaw = 5059584, mRawSize = 7589376
D/dalvikvm( 358): GC_CONCURRENT freed 1683K, 60% free 2859K/7107K, paused 4ms+4ms
Just to make sure I understand, the cm9 kernel now has the original motorola camera code? If so, that makes sense, and also please check liboemcamera.so.
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.
A 'blob' is the proprietary precompiled drivers that interface with the hardware and is provided by the manufacturer.
I didn't know that needed to be done. Why don't we just replace libcamera sources with libcamera2? Or were you just trying to keep things separate until we find what works?
I notice now that there's several places where QualcommCameraHardware.cpp exists (hardware/qcom/camerahal, hardware/qcom/libcamera2, hardware/msm7k/libcamera) and there are some differences b/w the files. Are these all being built and used? Can we just symlink the files so there's only one copy that needs to be modified? Not sure if the compiler will complain about that.
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...
Quote:
Originally Posted by adamto
mozzwald is right, in our case the blob is liboemcamera.so. You will see in QualcommCameraHardware, this library is dlopen()ed and these LINK_* functions are the blob interface. I was trying to track this down a little bit, but couldn't figure this out: where did our liboemcamera.so come from? It may be important that it is in sync with the kernel camera code and QualcommCameraHardware. Do you know if what we have checked in for these three pieces is from the same place?
Ah I was wondering about libcamera.so/libcamera2.so. I was going to try the other one but ran out of time last night.
Hmm, don't know much about overlays yet. Is there a problem with the htcoverlay?
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.
Quote:
Originally Posted by dsmryder
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.
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.
Last edited by BSydz; February 13th, 2013 at 06:03 PM.
I've tried both libcamera and libcamera2, tried the cm9, cm7, and stock liboemcamera.so. Same results with all. QualcommCameraHardware enters native_stop_video() and is getting hung up there (the ioctl is failing):
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.
The Following User Says Thank You to adamto For This Useful Post:
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:
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.
s->s_mount_angle = 0;
and this being commented out and moved from the middle of the file to the end
sensor_init_parameters(info,&mt9p111_parameters);
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.
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.
The Following 2 Users Say Thank You to BSydz For This Useful Post:
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:
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.
s->s_mount_angle = 0;
and this being commented out and moved from the middle of the file to the end
sensor_init_parameters(info,&mt9p111_parameters);
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.
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.
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.
The Following User Says Thank You to dsmryder For This Useful Post:
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:
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.
s->s_mount_angle = 0;
and this being commented out and moved from the middle of the file to the end
sensor_init_parameters(info,&mt9p111_parameters);
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.
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.
This is exactly the sort of thing I wanted to track down, thanks a bunch. I'll take a closer look after work.
Last edited by adamto; February 14th, 2013 at 01:38 PM.
The Following User Says Thank You to adamto For This Useful Post:
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.
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.
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...
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.
Hmm, don't know much about overlays yet. Is there a problem with the htcoverlay?
Quote:
Originally Posted by BSydz
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.
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.
Device(s): OV- MIUIgb with Suave HD theme, MT- AOKP with my own theme
Carrier: Not Provided
Thanks: 102
Thanked 507 Times in 185 Posts
Quote:
Originally Posted by BSydz
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.
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
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.
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?
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?
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.
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.
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.
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.
Going by what you said. I am looking at the board configuration for CM7 and CM9. CM7 uses
Code:
BOARD_CAMERA_USE_GETBUFFERINFO := true
Where CM9 uses
Code:
BOARD_USES_HTC_CAMERA := true
When this build finnishes I am going to try and swap then and just see what happens.
I 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.
Going by what you said. I am looking at the board configuration for CM7 and CM9. CM7 uses
Code:
BOARD_CAMERA_USE_GETBUFFERINFO := true
Where CM9 uses
Code:
BOARD_USES_HTC_CAMERA := true
When this build finnishes I am going to try and swap then and just see what happens.
Quote:
Originally Posted by dsmryder
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.
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 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.
415Likes
