Guest jgilalonso Posted January 5, 2012 Report Posted January 5, 2012 see the second post of this thread for what is working. Was tested with CM7.1rc1 Incredible!!!!! You're a genius!!! Only a questions: - What is not working? - What about performance, native tethering and openGL 2.0? - If CM7 is based on gingerbread, which is the difference between a kernel 2.6.32 (froyo) and 2.6.35 (ginger)? Can you upload a new ROM CM7.1 with your new kernel? Thanks a lot!!! I love my Pulse!!!!
Guest dr.flo Posted January 5, 2012 Report Posted January 5, 2012 (edited) And, for anyone who is interested: here is this kernel combined with dtox125 CM7.1 rom and ascend libcamera.so. You must have signature checking turned off in CWM to install this (files were exchanged in zip file). NOTE: the camera is NOT WORKING. Just install this if you want to see how this... With regard to camera I'm also getting simi-positive results. If on CM6 camera did't even try to start, on froyo stock rom I'm getting: - image with very weird inverted colors; - image freezes soon after. So I can't make a picture. ...looks like on CM7.1 BIG NOTE: this is just for people who want to experiment. I'm not able to support this in case of problems, I just copy-pasted some files from one ROM to another! Edited January 5, 2012 by dr.flo
Guest D-D- Posted January 5, 2012 Report Posted January 5, 2012 (edited) And, for anyone who is interested: here is this kernel combined with dtox125 CM7.1 rom and ascend libcamera.so. You must have signature checking turned off in CWM to install this (files were exchanged in zip file). So I just wanted to test this thing and I must say for no overclocked cm7 looks great. It's way more responsive than the cm7 on .29 (I know it's not just me, cause I could actually go to the settings and performance settings without lagging). I loved it, but I will go back to cm6 for a while. + the boot screen creeped me out at the beginning, but I love it, especially Tux! Edited January 5, 2012 by D-D-
Guest pier11 Posted January 5, 2012 Report Posted January 5, 2012 So I just wanted to test this thing and I must say for no overclocked cm7 looks great. It's way more responsive than the cm7 on .29 (I know it's not just me, cause I could actually go to the settings and performance settings without lagging). I loved it, but I will go back to cm6 for a while. + the boot screen creeped me out at the beginning, but I love it, especially Tux! Console with Tux there was for development, I removed it in source tree already :) Thanks for testing!
Guest D-D- Posted January 5, 2012 Report Posted January 5, 2012 Console with Tux there was for development, I removed it in source tree already :) Thanks for testing! Noo, get it back! You're welcome. Anyway, I don't know if it's rom or kernel thing, but it wouldn't indicate battery percentage and wouldn't turn on wifi. And I would guess that since it's still in dev, there is no OC on this kernel. Everything else worked great.
Guest pier11 Posted January 5, 2012 Report Posted January 5, 2012 No overclock so far. Not a priority in the moment. For wifi to work, a new kernel model is needed to be used (the previous one from .29 is not compatible). I've compiled from source the new one. Battery percentage is sort of side effect appeared after I added sound :) But in my recent compilations it looks like started to work again... (But anyway you should have percentage present in Settings->About...)
Guest pier11 Posted January 5, 2012 Report Posted January 5, 2012 Good introductory reading on Camera architecture on MSM platform: RFC: V4L2 driver for Qualcomm MSM camera
Guest pier11 Posted January 5, 2012 Report Posted January 5, 2012 OK, if include/media/msm_camera.h is API between propriatory MSM part in user space (libqcamera.so?? aka liboemcamera.so) and kernel, then: 1. API has not changed between Eclair and Froyo for MSM7225-based devices (like u8150 Comet/Ideos, u8110 pulse-Mini, etc.) 2. For the same devices it has changed between Froyo and Gingerbread. 3. Our API on Eclair is different to MSM7225's Eclairs above, and rather similar to pulse's Cupcake. I compiled .32 kernel with MSM7225 version of API. That's why u8150 camera libs work there, but not the pulse's libs from .29 kernel.
Guest dr.flo Posted January 5, 2012 Report Posted January 5, 2012 (edited) OK, if include/media/msm_camera.h is API between propriatory MSM part in user space (libqcamera.so?? aka liboemcamera.so) and kernel, then: 1. API has not changed between Eclair and Froyo for MSM7225-based devices (like u8150 Comet/Ideos, u8110 pulse-Mini, etc.) 2. For the same devices it has changed between Froyo and Gingerbread. 3. Our API on Eclair is different to MSM7225's Eclairs above, and rather similar to pulse's Cupcake. I compiled .32 kernel with MSM7225 version of API. That's why u8150 camera libs work there, but not the pulse's libs from .29 kernel. Interesting.... Lets think about what this means 1. we would like u8150 libcamera.so to work on the pulse because it is a native froyo binary (and therefore also could be used in CM7 gingerbread) 2. therefore we need (and now have) a kernel which exposes an API that matches 1. 3. our camera hardware works with .29 kernel drivers 4. both APIs are "slightly" different Right? Now possibly the most elegant solution would be to modify the kernels camera driver in a way that the API stays like it is in our kernel port now, and in the inside it should talk to the camera like .29 did. I did not look too closely at both API versions yet, but my first impression is that the differences are possibly not too large. Some parameters added, enums instead of defines, ... I think It might be possible to modify .29 drivers in such a way that they expose the same API as the MSM7225 What do you think? EDIT: what makes you think "2. For the same devices it has changed between Froyo and Gingerbread."? I believe this is not the case. As far as I know, Froyo binaries work in gingerbread with only a very minimalistic wrapper that basicly renames one or two functions. The interface kernel <-> user should not be affected Edited January 5, 2012 by dr.flo
Guest pier11 Posted January 5, 2012 Report Posted January 5, 2012 What do you think? I conceptually support it :) Interestingly, the camera drivers themselves are nearly identical in .29 and .32, but "something in between" implemented differently. That something in between is: msm_camera.c msm_vfe7x flash For .29 those were taken from somewhere else(.27?) and placed to separate folder drivers/media/video/msm/7x0x instead of using ones from original source tree. EDIT: what makes you think "2. For the same devices it has changed between Froyo and Gingerbread."? comparing include/media/msm_camera.h in .32 tree to one in .35 source tree
Guest dr.flo Posted January 5, 2012 Report Posted January 5, 2012 For .29 those were taken from somewhere else(.27?) and placed to separate folder drivers/media/video/msm/7x0x instead of using ones from original source tree. Maybe they needed a quick workaround because they got a "picture with very weird colors" when using the original source tree? Just kidding... This is the key I think... comparing include/media/msm_camera.h in .32 tree to one in .35 source tree ah, ok I understand. But nevertheless Ascend and u8150 all have identical libcamera.so in both their stock froyo versions and both their CM7 versions where camera is said to be working. Their CM7 maybe runs on .32 kernel? But I think this doesn't need to bother us.
Guest pier11 Posted January 6, 2012 Report Posted January 6, 2012 (edited) interesting reading on how camera stuff works: CameraVFE And more on parts of camera ecosystem Edited January 6, 2012 by pier11
Guest dr.flo Posted January 6, 2012 Report Posted January 6, 2012 (edited) pulse .29 struct msm_ctrl_cmd_t { int timeout_ms; uint16_t type; uint16_t length; void *value; uint16_t status; }; u8150 .32 struct msm_ctrl_cmd { uint16_t type; uint16_t length; void *value; uint16_t status; uint32_t timeout_ms; int resp_fd; /* FIXME: to be used by the kernel, pass-through for now */ }; Note the different position of the type/length element. Any libcamera compiled with one version of the header is definately unable to communicate with the camera driver compiled with the other version of the header... Can you provide some step by step instructions on what to do in order to compile your kernel from the repo?Maybe using this as a starting point? Edited January 6, 2012 by dr.flo
Guest pier11 Posted January 6, 2012 Report Posted January 6, 2012 (edited) Can you provide some step by step instructions on what to do in order to compile your kernel from the repo? Maybe using this as a starting point? Here they are: Building and packing the kernel into a flashable boot.img Tested all the steps in the instruction up until to phone works with the newly compiled kernel. Works. Edited January 6, 2012 by pier11
Guest skykilla Posted January 6, 2012 Report Posted January 6, 2012 (edited) Insertion cyanogenmod-plus-pulse-v0.9.1 and power consumption at height. cm7 sits down the battery in 2 times faster than cm6 who can will look cm6 why on it the battery is discharged not so quickly http://narod.ru/disk/32747712001/mod-2.2.1.rar.html Edited January 6, 2012 by skykilla
Guest pier11 Posted January 6, 2012 Report Posted January 6, 2012 OK, if include/media/msm_camera.h is API between propriatory MSM part in user space (libqcamera.so?? aka liboemcamera.so) and kernel, then: 1. API has not changed between Eclair and Froyo for MSM7225-based devices (like u8150 Comet/Ideos, u8110 pulse-Mini, etc.) 2. For the same devices it has changed between Froyo and Gingerbread. 3. Our API on Eclair is different to MSM7225's Eclairs above, and rather similar to pulse's Cupcake. I compiled .32 kernel with MSM7225 version of API. That's why u8150 camera libs work there, but not the pulse's libs from .29 kernel. libcamera/QualcommCameraHardware.cpp: #include <media/msm_camera.h> As thought, media/msm_camera.h defines interaction format between kernel and user space...
Guest romea Posted January 6, 2012 Report Posted January 6, 2012 (edited) To test the rom and the sort of link to download the kernel. currently employed and the touch screen? Edited January 6, 2012 by romea
Guest pier11 Posted January 7, 2012 Report Posted January 7, 2012 From what I gathered, 1. libcamera.so provides higher level user space API. (It also talks to proprietary libqcamera.so). 2. libcamera.so (QualcommCameraHardware.cpp) via ioctl talks to kernel. Receiving part is msm_camera.c in kernel. Interface is include/media/msm_camera.h 3. Communication with kernel goes via the following devices created by msm_camera.c via ioctl: /dev/msm_camera/config0 /dev/msm_camera/config1 /dev/msm_camera/control0 /dev/msm_camera/control1 /dev/msm_camera/frame0 /dev/msm_camera/frame1(As we have two cameras)
Guest dr.flo Posted January 7, 2012 Report Posted January 7, 2012 (edited) interesting findings... Have you ever looked at u8220's libcamera.so with a hex editor? It has the following string inside "hardware/msm7k/libcamera/7x0x/QualcommCameraHardware.cpp" So I strongly believe that the pulse uses a modified piece of code not only inside the kernel drivers, but also inside libcamera; must be, because of the different api. Also from what I have read, libqcamera (in the pulse's case libmmcamera + libmm-qcamera-tgt) contains the majority of hardware dependend functions, so I guess we can't just patch the kernel drivers to act like in .29 kernel (as I proposed before). Is this (libmmcamera + libmm-qcamera-tgt) part of older android versions (donut?). Then maybe the 7x0x subtree is a copy of donut's version. Are there sources of QualcommCameraHardware.cpp available for any donut device? This seems to be a version of libcamera source code that connects to old proprietary libmmcamera, but it is built for gingerbread... Maybe some combination of .29 kernel drivers + original libmmcamera / libmm-qcamera-tgt + recompiled libcamera would be feasible? edit: and thank you for the perfect instructions on building the kernel! Edited January 7, 2012 by dr.flo
Guest pier11 Posted January 7, 2012 Report Posted January 7, 2012 (edited) Pulse never experienced Donut (1.6), but had Cupcake (1.5). You probably know about Code Aurora project - open source from our chipset maker - Qualcomm. That is where Huawei's kernels ware derived from. (Huawei didn't change kernels significantly. Whereas Code Aurora departs quite significantly from AOSP - Android Open Source Project - Google's original version) So Code Aurora has libcamera for Cupcake (1.5) referencing our libs: libmmcamera = ::dlopen("libmmcamera.so", RTLD_NOW); libmmcamera_target = ::dlopen("libmm-qcamera-tgt.so", RTLD_NOW); AOSP's Cupcake references libqcamera instead: libqcamera = ::dlopen("libqcamera.so", RTLD_NOW); By comparing camera API it seemed to me that .29 version had more similarities to what was in .27 kernel (Cupcake) in Pulse. (Maybe they didn't want to license/pay for the new version of proprietary Qualcomm's libmm-qcamera-tgt.so & Co. - who knows) On the other hand .32 kernel holds camera drivers for our camera sensors; and that same sensors I think present on "true" .32 devices (ascend? pulse-mini?) So that makes me want use normal .32 interfaces/libs (and it kind of worked in half already), not to look backwards. Edited January 7, 2012 by pier11
Guest pier11 Posted January 7, 2012 Report Posted January 7, 2012 (edited) Further to differences between pulse-29 layer interactions and .32 Froyo (2.2) rom u8150 Expected devices: ...1MULTI-TOUCH_STOCK_ROM__u8150/system/lib$ strings libcamera.so | grep /dev /dev/pmem_adsp /dev/graphics/fb0 /dev/graphics/fb0 opened failed! /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq /dev/msm_camera/control /dev/msm_camera/config ...1MULTI-TOUCH_STOCK_ROM__u8150/system/lib$ strings libqcamera.so | grep /dev /dev/video20 /dev/graphics/fb0 /dev/msm_camera/frame /dev/msm_camera/control0 /dev/msm_camera/config /dev/pmem_adsp .32 kernel Available devices: sh-3.2# ls -l /dev/msm_camera/ crw-rw---- 1 1000 1000 246, 1 Jan 6 14:33 config0 crw-rw---- 1 1000 1000 246, 4 Jan 6 14:33 config1 crw-rw---- 1 1000 1000 246, 0 Jan 6 14:33 control0 crw-rw---- 1 1000 1000 246, 3 Jan 6 14:33 control1 crw-rw---- 1 1000 1000 246, 2 Jan 6 14:33 frame0 crw-rw---- 1 1000 1000 246, 5 Jan 6 14:33 frame1 sh-3.2# ls -l /dev/video20 crw------- 1 0 0 81, 0 Jan 6 14:33 /dev/video20 sh-3.2# ls -l /dev/graphics/fb0 crw-rw---- 1 0 1003 29, 0 Jan 6 14:33 /dev/graphics/fb0 sh-3.2# ls -l /dev/pmem_adsp crw-rw---- 1 1000 1005 10, 1 Jan 6 14:33 /dev/pmem_adsp Eclair (2.1) stock Pulse rom: Expected devices: ...Stock2.1/system/lib$ strings libcamera.so | grep /dev /dev/pmem_adsp /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq /dev/msm_camera/msm_camera /dev/oncrpc ...Stock2.1/system/lib$ strings libmmcamera.so | grep /dev /dev/video20 /dev/fb0 /dev/msm_camera/msm_camera /dev/pmem_adsp ...Stock2.1/system/lib$ strings libmm-qcamera-tgt.so | grep /dev /dev/pmem_adsp /dev/msm_camera/msm_camera /dev/LPMTASK /dev/adsp/LPMTASK .29 Pulse kernel Available devices: sh-3.2# ls -l /dev/msm_camera/ crw-rw---- 1 1000 1000 246, 0 Jan 7 18:01 msm_camera0 crw-rw---- 1 1000 1000 246, 1 Jan 7 18:01 msm_camera1 sh-3.2# ls -l /dev/pmem_adsp crw-rw---- 1 1000 1005 10, 1 Jan 7 18:01 /dev/pmem_adsp sh-3.2# ls -l /dev/adsp/LPMTASK crw-rw---- 1 1000 1005 250, 6 Jan 7 18:01 /dev/adsp/LPMTASK Notice mismatch of devices on 29-pulse vs 32 on the following node /dev/msm_camera/ When I tried to use our CM6 atop of .32 kernel no wonder I got: interface_init: msm_camera opened failed! If Huawei didn't use /7x0x folder, the API on .29 would be the same as on .32 systems. Edited January 7, 2012 by pier11
Guest dr.flo Posted January 7, 2012 Report Posted January 7, 2012 On the other hand .32 kernel holds camera drivers for our camera sensors; and that same sensors I think present on "true" .32 devices (ascend? pulse-mini?) So that makes me want use normal .32 interfaces/libs (and it kind of worked in half already), not to look backwards. You're right. Did you ever try out the patched CM7 I uploaded? Just to see if the camera behaviour there is really the same as in u8150 froyo? Now what should be done next? Do the logs give any hints about why the preview freezes? What I don't understand is why this happens if we really have the same HW as in those devices where the binaries are from. Shouldn't it just work then? btw, have you ever tried this phone info? Mine says I have a mt9t013_byd
Guest pier11 Posted January 7, 2012 Report Posted January 7, 2012 (edited) have you ever tried this phone info? Mine says I have a mt9t013_byd I've read that thread. I know mt9t013_byd is one of two variations of main sensors on our boards. Mine is ov3647. I didn't try patched cm7, but from your description it behaves similar to what I observed... On the other note, that libcamera source from motorola cliq xt, gibgerbread, - it might be what is needed to glue .29 infrastructure to cm7 (gingerbread). Try to compile it with cm7 :-) looks they use .29 kernel with gingerbread as we did initially. Edited January 7, 2012 by pier11
Guest pier11 Posted January 8, 2012 Report Posted January 8, 2012 (edited) Rather good news for idea of using froyo camera ecosystem. Looks like proprietary u8150's libqcamera.so has support for our cameras: ...1MULTI-TOUCH_STOCK_ROM__u8150/system/lib$ strings libqcamera.so | grep ov3 ov3647_process_start ov3647 ...1MULTI-TOUCH_STOCK_ROM__u8150/system/lib$ strings libqcamera.so | grep ov7 ov7690_process_start ov7690_format ov7690 ...1MULTI-TOUCH_STOCK_ROM__u8150/system/lib$ strings libqcamera.so | grep mt9 mt9t013_liteon_process_start mt9t013_byd_process_start mt9d113_process_start mt9d112_process_start mt9p012_register_to_real_gain mt9p012_process_start mt9p012_set_lens_shading_correction mt9p012_km_register_to_real_gain mt9p012_km_process_start mt9p012_km_set_lens_shading_correction mt9t013_process_start mt9t013_reg_pat mt9d113_format mt9t013_liteon mt9t013_byd mt9d113 mt9p012 failed %d This is used on u8120 ...1MULTI-TOUCH_STOCK_ROM__u8150/system/lib$ strings libqcamera.so | grep s5k s5k5ca_process_start s5k5ca_format s5k3e2fx_process_start s5k5ca And thought that libqcamera has tons of hardware specific stuff looks right. Edited January 8, 2012 by pier11
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now