UPDATE !! The drivers for the front camera are found ! Check the latest CM9/CM10 ROM's and the drivers should be incorporated !
-----------
This topic is for devs and testers only. Please keep this topic as clean as possible. So only post if you have some new information to share.
The idea of this thread is to gather all the information we have regarding the 10.1v camera so that a developers can port the camera drivers to ICS.
What do we know already?
1. Back camera lens: Sony IMX-073 - CMOS : OV-8820 (technical specification)
2. Front camera lens: Samsung S5K5BBGX - CMOS : OV-9640
3. The Samsung Galaxy S II is using a IMX-105 lens and NOT an IMX-073 lens as we assumed. However, the CMOS chip is identical: OV-8820 in both devices. So in theory we should be able to use the same driver.
4. In HC 3.2 the device drivers are:
camera0=/dev/imx073,back,0,mono
camera1=/dev/os5k5bbgx,front,0,mono
There is a mention of IMX073 in this lib: \system\lib\libnvodm_imager.so
I guess the following files are impacted as well:\system\lib\libcamera.so
5. Honeycomb Sources for our Camera drivers (2.6 kernel):
- IMX073 & s5k5bbgx : https://github.com/cyanogen/galaxy-2636/tree/ics/drivers/media/video/tegra
- IMX073 : https://www.codeaurora.org/patches/quic/la/PATCH_MSM7x30_1969_Sony-IMX073-Driver_20100608.tar.gz
-----------------------------------------------------------------
What needs to be done?
-> Many data structures have changed between HC & ICS. There are many fundamental changes in the way memory is shared for preview/pictures/video, so that will need to be addressed. This is a rather painful process, but it can be done. There is a chance when Samsung releases the ICS rom for the 10.1, that we can use it for the 10.1v. But probably this driver will not have proper support for our camera model. So we can only hope for the best!
UPDATE: The best option is that someone writes a HAL (Hardware Abstraction Lager) module for Tegra 2 SoC's. If my information is correct, that means that the hardware calls to the SoC need to be reverse engineered. Once we have this HAL module, developers can write a wrapper around the old (Gingerbread 2.6 kernel) camera driver. With this HAL module all Tegra 2 devices have a good chance of getting the camera to work. The good news is that there are a lot of Tegra 2 devices, so the community is big and there is a fair chance a skilled developer will develop a HAL for it.
-----------------------------------------------------------------
Attempts to make it work so far
I've tried the Samsung Galaxy S II camera libs (same camera model) and the Motorola Xoom (same Tegra 2 chipset but different camera model) camera libs, but without success.
Error codes are visible in logcat:
- S II libs: signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 5b3804a2
- Xoom libs: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00010ef0
- Old HC libs: isimobile tried with the HC libs without success -> check here
-----------------------------------------------------------------
If you have any information to share, please post in this topic.
Thanks
I've been doing some more digging and I've found this driver source for the IMX073.
Could it be of any use for us?
Just a quick brainstorming:
If the module is the same as in the SII wouldn't it be possible to use the driver from the ICS update for the SII once that's out?
Update: the front camera is actually a 's5k5bbgx'
And the source code appears to be on github already (pushed by pershoot for the p5 device)
So I really think pershoot should take a look at this topic
https://github.com/cyanogen/galaxy-2636/tree/ics/drivers/media/video/tegra
already posted this in the isi ICS thread, but also suited here
In regards to make the camera working maybe pershoot, isimobile or another person with the knowledge on how to do it, XDA member twistedumbrella made the camera work for a lot of HTC devices under ICS. He had no source from HTC, he took the Gingerbread driver, decoded it and modified it so it would work with ICS. Maybe anybody can contact him to ask how he did it, so maybe we can do it too with our Honeycomb driver
Just a thought
ORiZorrie said:
What needs to be done?
-> Many data structures have changed between HC & ICS. There are many fundamental changes in the way memory is shared for preview/pictures/video, so that will need to be addressed.
Click to expand...
Click to collapse
I've asked this in the KANG thread already, but didn't receive an answer. Maybe here it may draw attention of the right ppl
XaMaB said:
Is there a chance this work (with modifications of course) for our cameras?
[WIP] - ICS Camera HAL for 2.6 kernel
Click to expand...
Click to collapse
Psyloid said:
XDA member twistedumbrella made the camera work for a lot of HTC devices under ICS.
Click to expand...
Click to collapse
I have sent him a mail. I hope he's open to that because he's not accepting private messages. In any case, I'm just trying to gather as much information as possible. We'll see if he replies or not....
XaMaB said:
Is there a chance this work (with modifications of course) for our cameras?
[WIP] - ICS Camera HAL for 2.6 kernel
Click to expand...
Click to collapse
Thanks. I have already looked into that code, but it's for Qualcomm SoC's, and not for Tegra 2. We would need a HAL (Hardware Abstraction Layer) module for Tegra 2 instead I guess...
I have done some further testing:
I back ported tegra_camera.c from the nvidia 2639 kernel. tegra_camera.c is being called from imx073, in a couple of places. The driver seems to be loading ok and if I open the camera app, it does not FC anymore, but the device "hangs". I have to forcefully reboot it to get to work again.
What it looks like is that the problem is libnvodm_imager.so. That is what we found earlier that that library have hardcoded values for the camera. The lib we are using is looking for OV5640 camera which it the transformer (TF101) camera. So unless we can get a working libnvodm_imager.so. I think we are stuck. I tried to hexedit the values in the lib to imx073/s5k5bbgx, but did not make any difference.
Comments suggestions are welcome.
Here is a portion of the logcat:
Code:
D/NvOsDebugPrintf( 112): +NvOdmImagerOpen (202):ImagerGUID= (0), Handle=0x702134
D/NvOsDebugPrintf( 112): NvOdmImagerOpen (203):Compiled at Feb 21 2012 21:26:41
D/NvOsDebugPrintf( 112): NvOdmImagerOpen (205):prop: force.camera=Unknown
D/NvOsDebugPrintf( 112): NvOdmImagerOpen (251):ioctl failed!
D/dalvikvm( 1166): GC_FOR_ALLOC freed <1K, 7% free 8489K/9095K, paused 22ms
I/dalvikvm-heap( 1166): Grow heap (frag case) to 8.770MB for 331516-byte allocation
D/NvOsDebugPrintf( 112): +SensorYuv_Open (362):compiled at Feb 21 2012 21:26:41
D/NvOsDebugPrintf( 112): +check_project (31):
D/NvOsDebugPrintf( 112): check_project (33):prop: ro.epad.model=Unknown
D/NvOsDebugPrintf( 112): -check_project (42):undefined...!
D/NvOsDebugPrintf( 112): +ParsingCustomCap (156):
D/NvOsDebugPrintf( 112): -ParsingCustomCap (171):
D/NvOsDebugPrintf( 112): SensorYuv_Open (386):Custom Cap not found, use built-in one.
D/NvOsDebugPrintf( 112): -SensorYuv_Open (397):
D/NvOsDebugPrintf( 112): +SensorYuv_GetCapabilities (422):
D/NvOsDebugPrintf( 112): -SensorYuv_GetCapabilities (427):
D/NvOsDebugPrintf( 112): NvOdmImagerGetCapabilities (535):identifier:OV5640
isimobile said:
I back ported tegra_camera.c from the nvidia 2639 kernel. tegra_camera.c is being called from imx073, in a couple of places. The driver seems to be loading ok and if I open the camera app, it does not FC anymore, but the device "hangs". I have to forcefully reboot it to get to work again.
Click to expand...
Click to collapse
https://github.com/cyanogen/galaxy-2636/blob/ics/drivers/media/video/tegra/imx073.c
If I look in the imx073.c file I don't see those references you mention apart from the header file reference 'media/tegra_camera.h'.
isimobile said:
What it looks like is that the problem is libnvodm_imager.so. That is what we found earlier that that library have hardcoded values for the camera. The lib we are using is looking for OV5640 camera which it the transformer (TF101) camera. So unless we can get a working libnvodm_imager.so. I think we are stuck. I tried to hexedit the values in the lib to imx073/s5k5bbgx, but did not make any difference.
Click to expand...
Click to collapse
The photosensor for s5k5bbgx is OV9640 (see OP -> it's mentioned in the header of s5k5bbgx.c)
The photosensor for imx073 is OV8820 (see OP)
Simply hexediting the values in the lib won't work. Reverse engineering implies that you disassemle the code, edit it (assembled language) and then assemble it again.
What we need is a HAL module for Tegra 2 SoC's, When we have that HAL module porting the device driver should be more straightforward (at least if you're a C adept) because we can reuse the old driver.
ORiZorrie said:
https://github.com/cyanogen/galaxy-2636/blob/ics/drivers/media/video/tegra/imx073.c
If I look in the imx073.c file I don't see those references you mention apart from the header file reference 'media/tegra_camera.h'.
The photosensor for s5k5bbgx is OV9640 (see OP -> it's mentioned in the header of s5k5bbgx.c)
The photosensor for imx073 is OV8820 (see OP)
Simply hexediting the values in the lib won't work. Reverse engineering implies that you disassemle the code, edit it (assembled language) and then assemble it again.
What we need is a HAL module for Tegra 2 SoC's, When we have that HAL module porting the device driver should be more straightforward (at least if you're a C adept) because we can reuse the old driver.
Click to expand...
Click to collapse
Have a look in camerafw_file_cmd_show: tegra_camera_enable_vi, tegra_camera_enable_csi
Send from my GT-P7100
Good job guys... keep up the great effort. Remember you're not making a thousand mistakes, just finding a thousand ways not to do it
Sent from my Inspire 4G using XDA
I say: drop all efforts to get a working rear camera on the Tab! I can live without that one. The front one, on the other hand, is crucial for everything from Skype, to Google Talk, to any number of other video chat apps which are way more practical on a tablet than using it as a huge camera. Front-facing first; rear-facing second
Great effort by all though; I love you guys! No homo
Just a quick note; If camera starts in the kernel, but doesn't start in Android itself, it's very likely that you will have to do some modifications to libcamera.so so that Android won't produce that error you have on the original post. I do not know exactly what the mods are, sadly, I wasn't fast enough on stalking the repositories
PookiePrancer said:
I say: drop all efforts to get a working rear camera on the Tab! I can live without that one. The front one, on the other hand, is crucial for everything from Skype, to Google Talk, to any number of other video chat apps which are way more practical on a tablet than using it as a huge camera. Front-facing first; rear-facing second
Great effort by all though; I love you guys! No homo
Click to expand...
Click to collapse
QFT
The front camera is far more valuable than the rear. If I can find some time, I may start poking around with getting this working too. I hate the idea of rolling back to stock just to use Skype.
i hate to sound like a noob since i am not a dev at all, but has anyone tried the cm9 galaxy s 2 libs since they got the camera/camcorder working properly? this has just happened in the last few days. maybe something has changed since then.
insaneturbo13 said:
i hate to sound like a noob since i am not a dev at all, but has anyone tried the cm9 galaxy s 2 libs since they got the camera/camcorder working properly? this has just happened in the last few days. maybe something has changed since then.
Click to expand...
Click to collapse
Galaxy S II has both a different camera and SoC, so its not of much help.
GazaIan said:
Galaxy S II has both a different camera and SoC, so its not of much help.
Click to expand...
Click to collapse
well, the lens is different yes, but the cmos chips is the same, which is what counts, however the soc is is different... very different lol.
insaneturbo13 said:
well, the lens is different yes, but the cmos chips is the same, which is what counts, however the soc is is different... very different lol.
Click to expand...
Click to collapse
Yeah, and if what I understood from KANG is correct... before you can do ANYTHING driver related you need to be able to communicate with the SoC. So I'm afraid that is the biggest showstopper at this time.
About the front/rear camera I think that one might work once there is an ICS update for the GTab 10.1. Normally that cam should be very similar if not identical.
ORiZorrie said:
Yeah, and if what I understood from KANG is correct... before you can do ANYTHING driver related you need to be able to communicate with the SoC. So I'm afraid that is the biggest showstopper at this time.
About the front/rear camera I think that one might work once there is an ICS update for the GTab 10.1. Normally that cam should be very similar if not identical.
Click to expand...
Click to collapse
Question is, does Samsung love us enough to get us an update
Related
This version of the camera is reported to have a "macro" feature and from pictures I've seen, I'm digging the UI. I've got a SGS TMO Vibrant and wanted to try and push the deodexed camera.apk from the Nexus S GB build to my phone to see if my camera hardware is capable of the "macro" feature.
EDIT:
For those unfamiliar with what "Macro" mode is / means...
http://www.talkandroid.com/23979-nexus-s-camera-includes-macro-focus-mode/
If you figure it out let us know I have a vibrant
Same here man, would love to use the nexus s camera apk..
Sent from my SGH-T959 using XDA App
Haven't heard anything yet. I am mostly clueless about how to deodex an APK but that can be learned given time. Haven't looked into it enough. I just wonder if the camera.apk is relatively standalone or also has library / framework dependencies that will be need to deodexed as well. Hopefully nothing about the camera is tied to Gingerbread / the new GB SDK API level. If that's the case, it's totally out of my league for now.
With the fast progress being made on getting GB to run on the SGS family of phones though, I'm going to wait a bit to see if a flashable, bootable GB becomes available that includes the Camera. If that's the case, having the camera for Froyo might become a secondary concern.
Would any Nexus S users care to comment on how well the "Macro" feature of the camera works? I don't expect it to be DSLR quality but how does it compare?
I have the Nexus S I guess i dont know what you mean by the macro feature...
I can pull the apk for you if that helps
epakrat75 said:
Would any Nexus S users care to comment on how well the "Macro" feature of the camera works? I don't expect it to be DSLR quality but how does it compare?
Click to expand...
Click to collapse
Here's what I meant by Macro mode...
http://www.talkandroid.com/23979-nexus-s-camera-includes-macro-focus-mode/
Yes, having the APK posted here might be useful. I was assuming it wouldn't be a standalone package but I'll try it if posted. It might be easier than I thought.
huh.. didn't notice that option before...
Here's the apk
For those interested...
Installation of the attached APK file throws a parsing error during installation. Upon inspecting the logcat, I see that reason for this is: "Requires newer sdk version #9 (current version is #8)". For those unaware, #8=2.2 Froyo and #9 = 2.3 Gingerbread. The APK will likely need to be modified before it can even have a chance at installing / running on anything pre-Gingerbread.
I decompiled the APK. Then I opened up AndroidManifest.xml and changed the "9" to "8" in the 2 places that I found it listed. However, I don't know how to recompile it so I can place it back in the APK. Do I have to recompile the whole APK or is there a way to just do this one file / replace it in the already compiled APK? Signing it is optional, right?
Marmle said:
huh.. didn't notice that option before...
Here's the apk
Click to expand...
Click to collapse
Can someone give a noob step by step instructions on how to install this?
I really want the nexus s camera app on my galaxy s.
+1 request for Froyo patch
This thread has gone on a different approach on resolving this, so I'll be setting aside my old post (I wont be deleting them for some reasons). Everything under the hash army (###) in this single post is about getting the Spica stuff on the O1. We moved to focusing on the O1's ts driver itself.
Other note: Fixes are independent. Choose whichever works for you. A universal fix may come in the future though (Tell me if this post still confuses you. I'll edit ASAP)
Multitouch axis inversion fix (First release: Feb 6, 2011): Forum member waleedq came up with a workaround that inverts the inversion. This seems very straightforward, and it works. Please note, however, that this is a workaround and not a fix. As always, do a backup.
Stuff you should know:
- Most of us who tried it (inc. me), lost our OC.
- mik_os' touchscreen lag fix is here. Tested it with Android Status while touching the screen.
- Axis inversion is still a problem. Check video 2.
Videos: http://forum.xda-developers.com/showpost.php?p=11178060&postcount=67
Link to the download link: http://forum.xda-developers.com/showpost.php?p=11166426&postcount=47
waleedq's source: https://github.com/waleedq/ThunderG-Kernel/blob/thunderg_oc/drivers/input/touchscreen/mcs6000_ts.c
Faster readout fix (First release: Feb 8, 2011) : Der_Caveman released for testing a kernel with some delay fix (modified from stock kernel). Apparent goals were to make touchscreen input readouts faster. Also, useless and non-working functions that doesn't work were removed. No CPU spike (somewhere around 30%cpu use when touching screen)
UPD: v3 is based on drellisdee's kernel source, so yes, it's OCable.
Link to download link: http://forum.xda-developers.com/showpost.php?p=11195243&postcount=84
Link to download link(v3): http://forum.xda-developers.com/showpost.php?p=11221504&postcount=126 or a forum upload http://forum.xda-developers.com/showpost.php?p=11230915&postcount=137
Changes and stuff: http://forum.xda-developers.com/showpost.php?p=11206827&postcount=91
Touchscreen optimization + axis inversion workaround(First release: Feb 10, 2011):Der_Caveman and waleedq's work combined by Sippolo.
Link to download link + source + details: http://forum.xda-developers.com/showpost.php?p=11256797&postcount=198
Link to download link + source + details (v1.1): http://forum.xda-developers.com/showpost.php?p=11270721&postcount=237
#########################################################
Okay, so I just recently found out that the Galaxy Spica (was supposed to choose it over the O1 --') -unofficially- supports multitouch.
A link to the driver's was PMed to me by adi4motion:
https://github.com/Gabriel-LG/i5700-multitouch-kernel
Anyway, is it possible that we could implement their method on our drivers? I understand that there might be some hardware differences between the two. I'm just trying my luck
Lastly, for sample videos, check YouTube. I have to say that the performance with those drivers really are impressive (well, I saw the axis invert once)
https://github.com/Gabriel-LG/i5700-multitouch-kernel/tree/master/drivers/input/touchscreen
I didn't find any melfas drivers in there- so I doubt that the Galaxy Spica has a melfas touchscreen controller in it.
But it's possible that we could write a driver based on those, right?
only kpbotbot can do tht and i hope he does
What about O1 brother the LG Chic? Does it have the same issues?
Sent from my LG-P500
ccdreadcc said:
only kpbotbot can do tht and i hope he does
Click to expand...
Click to collapse
Sorry, can't code. But I assure you, I'm trying my best not to just leech (And I'm still figuring out how to compile FroYo to learn how ROMs get born)
N3mesis said:
What about O1 brother the LG Chic? Does it have the same issues?
Click to expand...
Click to collapse
There may be a guy here in the forum that has the Chic. Maybe he can test out the inversion issues (If you're reading this and you have the Chic, please test if the axis inverts using a tool like touch test xD)
kpbotbot said:
But it's possible that we could write a driver based on those, right?
Click to expand...
Click to collapse
In the O1 a melfas MCS6000 touchscreen controller reads the capacitive touchscreen. The controller itself got a proprietary firmware in it (don't know if its from melfas or LG)- you can find that somewhere in the system folder (melfas.bin(?)). Then there is the LG kernel driver which "interacts" with the melfas controller ic- it also has the ability to flash the melfas controller.
So if there is a problem in the MCS6000 firmware- we're most likely screwed, because lack of datasheets.
Furthermore I want to know how android gets the multitouch data. Maybe the android interface itself is not that multitouch friendly?
The easiest way would have been that each finger represents a "mouse event", but I doubt that this way was chosen...
I see. Is it possible to decompile that .bin somehow? I know, that question might sound stupid xD
I too did a search for melfas related stuff including source codes and the like. The only stuff I found was about Samsung phones having the same touch screen.
Let's just hope (for now that we cant do anything about it) that LG -at least- releases an improved version of their drivers for their 2.3 update
Update: The Chic has the same problem :/
http://forum.xda-developers.com/showpost.php?p=11014035&postcount=5
Maybe the axis inversion is somehow also android related.
Multitouch is something new for linux.
Der_Caveman said:
Maybe the axis inversion is somehow also android related.
Multitouch is something new for linux.
Click to expand...
Click to collapse
I think is just the crappy touch controller that's installed on our device; It can't spot more than 2 touches, and has got axis inversion. So I don't think there's so much to do with drivers
kite86 said:
I think is just the crappy touch controller that's installed on our device; It can't spot more than 2 touches, and has got axis inversion. So I don't think there's so much to do with drivers
Click to expand...
Click to collapse
LG only implemented "two fingers"- one can read that in LG's sources.
Again: axis inversion could also be android related (if android only requests coordinates without "finger assignments" bugs are preassigned).
I don't really care whether it would accept more than 2 presses That would be awesome for people doing extreme gaming with the phone, but with normal use it's awkward to use 3 fingers.
I bet the axis inversion issue is very much fixable. We just don't know how yet. But considering the fact that the Spica has less of this as a problem, we might fix it a bit, or completely fix it.
This is just my opinion though. I saw some guy explain multitouch with an illustration.
Wow, I have found this:
http://www.mjmwired.net/kernel/Documentation/input/multi-touch-protocol.txt
Just had to open my eyes
Let's see...
kpbotbot said:
I bet the axis inversion issue is very much fixable. We just don't know how yet. But considering the fact that the Spica has less of this as a problem, we might fix it a bit, or completely fix it.
Click to expand...
Click to collapse
You are 100% sure that the Spica does not have "the axis inversion bug"?
Der_Caveman said:
You are 100% sure that the Spica does not have "the axis inversion bug"?
Click to expand...
Click to collapse
I'm 100% sure.
I talked to a guy who used to own the phone. He said the drivers perform well.
I didn't say that there really was no inversion. It happens less (inverted once on the video I watched)
kpbotbot said:
I talked to a guy who used to own the phone. He said the drivers perform well.
I didn't say that there really was no inversion. It happens less (inverted once on the video I watched)
Click to expand...
Click to collapse
Ok, then I would say there is hope.
Der_Caveman said:
Ok, then I would say there is hope.
Click to expand...
Click to collapse
I sure do prey that someone will take this project and fix the driver or write it from scrath. As i can see the code is not that long
our driver
https://github.com/mik9/ThunderG-Kernel/blob/master/drivers/input/touchscreen/mcs6000_ts.c
spica's driver
https://github.com/Gabriel-LG/i5700...4461c4a3d4e2be0b5f4b1a94b451604c6541f1#diff-0
I have 2 months of doing absolutely nothing at home (stopped this sem. doctor said i have to rest. and yes, I have a life xD), so I might be able to understand a bit of the code. It really isn't that complex, but my lack of programming knowledge hinders me from modifying the code.
However, I sure do hope that someone figures this out
Hi, guys,
SNAPSHOT:
see Kalim's ROM release thread. Enjoy!
PS, sources have been synced with my github repo. check out this commit.
I met a problem to understand the assemble codes of a KEY function(ie reg_unreg_buf() in libcamera.so in Tattoo Donut system). I just know a little about arm assembly language. How does the assembly deal with structures and pointers to structer in C? If we can implement this function into libcamera.so in Froyo, I think it's not too far from working camera preview. So here are some details.
Current question is, why msm_poll in the kernel won't be called while I did system-call select()? I tried lots of times, but always no luck.
Forget them all, thanks to boz_x.
I will try to take a look into it this evening
KalimochoAz said:
I will try to take a look into it this evening
Click to expand...
Click to collapse
OK, thanks in advance. What confused me is what layout should be token in stack by arm assembly for structure data in C/C++. Are they exactly same as structures in memory or would arm-eabi-gcc apply some padding as well?
cn.fyodor said:
Hi, guys,
I met a problem to understand the assemble codes of a KEY function(ie reg_unreg_buf() in libcamera.so in Tattoo Donut system). I just know a little about arm assembly language. How does the assembly deal with structures and pointers to structer in C? If we can implement this function into libcamera.so in Froyo, I think it's not too far from working camera preview. So here are some details.
Current question is, why msm_poll in the kernel won't be called while I did system-call select()? I tried lots of times, but always no luck.
Forget them all, thanks to boz_x.
Click to expand...
Click to collapse
?¿? What do you mean. Something to share with us?
KalimochoAz said:
?¿? What do you mean. Something to share with us?
Click to expand...
Click to collapse
No, not currently. I just solve some little problems that I met. Addresses of frame I got were always wrong. Codes are messed up right now. Time to rest. Good night.
cn.fyodor said:
No, not currently. I just solve some little problems that I met. Addresses of frame I got were always wrong. Codes are messed up right now. Time to rest. Good night.
Click to expand...
Click to collapse
git your code to reach this. I will continue there if you want. here is 5 pm
cn.fyodor said:
Hi, guys,
Here is the color spectrum :
Click to expand...
Click to collapse
Does that image ever change. or is it static?
I'm wondering if perhaps it's data from the camera, just not in the format the app is expecting...
cn.fyodor said:
hi, guys,
i met a problem to understand the assemble codes of a key function(ie reg_unreg_buf() in libcamera.so in tattoo donut system). I just know a little about arm assembly language. How does the assembly deal with structures and pointers to structer in c? If we can implement this function into libcamera.so in froyo, i think it's not too far from working camera preview. So here are some details.
current question is, why msm_poll in the kernel won't be called while i did system-call select()? I tried lots of times, but always no luck.
forget them all, thanks to boz_x.
This is my wireless headset(8 frames overlapped ):
ps, sources have been synced with my github repo. Check out this commit.
Click to expand...
Click to collapse
i love you fn.fyodor
KalimochoAz said:
i love you fn.fyodor
Click to expand...
Click to collapse
We all <3 u fyodor!
Looks like messed yuv422, where green is Y and UV are black and light gray
Probably proportions are right but surface configured wrong
CAMERA WORKS ( No problem now )
Fyodor & Arco. I have already solved.
I would like to release the 3 versions at the same time. Fyodor PM me and we manage to release it all the ROMs with fully camera!!!!!!!!!!!!!!!!!!!!
YUPIEEEE!!!!
kalimochoaz said:
fyodor & arco. I have already solved.
I would like to release the 3 versions at the same time. Fyodor pm me and we manage to release it all the roms with fully camera!!!!!!!!!!!!!!!!!!!!
Yupieeee!!!!
Click to expand...
Click to collapse
devs are the best. Thank you!!!
I missed Fyodor a lot. We needed to be 3 coding to solve that puzzle
KalimochoAz said:
Fyodor & Arco. I have already solved.
I would like to release the 3 versions at the same time. Fyodor PM me and we manage to release it all the ROMs with fully camera!!!!!!!!!!!!!!!!!!!!
YUPIEEEE!!!!
Click to expand...
Click to collapse
See, this is why the HTC Tattoo communtity is so awesome!!
Keep up the good work!!
-- Kiljacken
well camera is now working. great! what about the video camcorder? is it gonna work too?
KalimochoAz said:
Fyodor & Arco. I have already solved.
I would like to release the 3 versions at the same time. Fyodor PM me and we manage to release it all the ROMs with fully camera!!!!!!!!!!!!!!!!!!!!
YUPIEEEE!!!!
Click to expand...
Click to collapse
How did you solve the y_cbcr offset issues? Actually I really don't know what they are, I just read the assembled codes step by step and fill my implementing function codes. LOL
And I don't mind the time when devs release their ROMs, so just go on your way, I will release my AOSP ROMs at a proper period.
Cheers && Enjoy!
when cn.fyodor just return to this forum FM radio works and now Camera preview.
Now I see the reason for buying this tattoo.
Big thanks to Kalim...and all others
Thank you guys. Thanks kalim, arco, fyodor
Excellent work.
My opinion
Let me say one think: Its really amazing and good to spend time with fn.Fyodor and Arco68 in this forum. When I change my device I will miss this way of working.
KalimochoAz said:
Let me say one think: Its really amazing and good to spend time with fn.Fyodor and Arco68 in this forum. When I change my device I will miss this way of working.
Click to expand...
Click to collapse
Thanks a lot Guys!
What device are you going to?? ( I want to go to the same!!)
I am looking at the Optimus 2x, it is a lot less expensive then the Galaxy S II!
Hi Guys,
I know I'm VERY quiet these days as I continue my personal vendetta against the Gingerbread/ICS hw codecs... but I thought I'd share with you a log sample from the Droid 3.
http://pastebin.com/raw.php?i=aLeLSu6y
That's the entire camera init:
- All of the camera properties are setup
- 6 preview buffers are allocated and registered
- followed by a few seconds of blank preview frames being loaded to/from the 6 buffers
- and then I "back" button out of the Camera UI near the end of the log
You can see the blank preview frames in the log by searching for "Buffer was never with Ducati!! 0x45d65000"
Those blank preview frames are what's holding up the show right now.
I know a lot of what you see me doing is working on RAZR and other projects, but in reality I spend at LEAST 2 hours every night troubleshooting and trying different techniques to get our ICS buffers to be recognized by our Gingerbread hw codec system.
if it isnt one thing its another eh?
is this the ICS camera software or the blur camera?
ssinisterss said:
if it isnt one thing its another eh?
is this the ICS camera software or the blur camera?
Click to expand...
Click to collapse
On twitter he said hes working on both. It's a matter of which works first.
ssinisterss said:
if it isnt one thing its another eh?
is this the ICS camera software or the blur camera?
Click to expand...
Click to collapse
This log uses the ICS camera. You can see some of the ICS stuff being setup in the beginning.
Sent from my XT912 using XDA App
Hashcode said:
This log uses the ICS camera. You can see some of the ICS stuff being setup in the beginning.
Sent from my XT912 using XDA App
Click to expand...
Click to collapse
Hey Hash... Just to ask but did you get the email I sent you a couple days ago? I can send it again if you would like.
Hashcode said:
This log uses the ICS camera. You can see some of the ICS stuff being setup in the beginning.
Sent from my XT912 using XDA App
Click to expand...
Click to collapse
everythingwentbetterthanexpected.jpg
are these previews going to be tied into something that needs to be re written? or are they little independent executions?
ssinisterss said:
everythingwentbetterthanexpected.jpg
are these previews going to be tied into something that needs to be re written? or are they little independent executions?
Click to expand...
Click to collapse
The camera preview frames are processed asynchronously (very fast) by the ducati processor, which triggers a callback to display them to the screen (30 times a second).
So the fix for this would be the same fix that needs to happen for the hw video playback codec where buffers are allocated and handed off to the ducati to decode a Netflix movie, etc.
Hashcode said:
The camera preview frames are processed asynchronously (very fast) by the ducati processor, which triggers a callback to display them to the screen (30 times a second).
So the fix for this would be the same fix that needs to happen for the hw video playback codec where buffers are allocated and handed off to the ducati to decode a Netflix movie, etc.
Click to expand...
Click to collapse
ok, that was making sense, basically as you move forward with fixing the codecs it will get handled versus the memory tiler where you had to take steps back to clean up.
are the codecs also responsible for sound recordings and the hdmi output? i noticed i wasnt able to listen to mms'd soundclips.
Dude...you forgot a comma on line 1278457659308493702761257357 of the module source. Easy fix. LOL! Seriously...let me know if you run out of beer.
I noticed this
I/Thumbnail(1392): Fail to load bitmap. java.io.FileNotFoundException: /data/data/com.android.camera/files/last_thumb: open failed: ENOENT (No such file or directory)
I hope it helps
Droid 1 Rooted (ChevyNo1 0.9MV Kernel, LGB2.6)
Droid 3 Rooted (Hashcode gave me some Ice Cream)
gVibeR said:
Dude...you forgot a comma on line 1278457659308493702761257357 of the module source. Easy fix. LOL! Seriously...let me know if you run out of beer.
Click to expand...
Click to collapse
its really missing a comma?
ssinisterss said:
its really missing a comma?
Click to expand...
Click to collapse
I think he was joking
Sent from my DROID3 using xda premium
yea i got it after looking at the log again
I'm sure you saw this, but it looks like there are too many derefs of the the frame buffer:
02-08 11:21:21.934: E/CameraHAL(221): hardware/ti/camera/OMXCameraAdapter/OMXCameraAdapter.cpp:2945 OMXCameraAdapterFillBufferDone - pBufferHeader->nOutputPortIndex == 2
02-08 11:21:21.934: D/CameraHAL(221): hardware/ti/camera/BaseCameraAdapter.cpp:1226 __sendFrameToSubscribers - Empty Frame Queue
02-08 11:21:21.934: D/CameraHAL(221): hardware/ti/camera/OMXCameraAdapter/OMXCameraAdapter.cpp:3135 OMXCameraAdapterFillBufferDone - sendFrameToSubscribers error: -22
02-08 11:21:21.934: D/CameraHAL(221): hardware/ti/camera/BaseCameraAdapter.cpp:302 returnFrame - Frame returned when ref count is already zero!!
Click to expand...
Click to collapse
Stock D3, eagerly awaiting CM9 cam support. (Thanks for your work!)
Dude...you rock.
Sent from my XT862 using XDA App
I know that I'm not contributing anything here, but I would like to express my gratitude to you.
All of the work that you've put into porting ICS to the Droid 3 is greatly appreciated by so many of us here; and now that the Chrome for Android beta is now out, since it only works on ICS, I'm definitely not going to switch to any other rom on the D3!
Thanks so much for your hard work and for your hasty replies to anyone who asks you questions, and the best of luck to you in regards to the camera!
wgoeken said:
I know that I'm not contributing anything here, but I would like to express my gratitude to you.
All of the work that you've put into porting ICS to the Droid 3 is greatly appreciated by so many of us here; and now that the Chrome for Android beta is now out, since it only works on ICS, I'm definitely not going to switch to any other rom on the D3!
Thanks so much for your hard work and for your hasty replies to anyone who asks you questions, and the best of luck to you in regards to the camera!
Click to expand...
Click to collapse
Yep the Chrome for Android beta is yet another reason I keep banging my head against the hw codecs.
You can do it!
i was screwing around with the CM9 rom from the photon that has a working camera, and putting files into our CM9 last night and the camera UI fired up for me but there was nothing on the viewfinder. i dont even remember what i did since i did a clean flash after
ssinisterss said:
i was screwing around with the CM9 rom from the photon that has a working camera, and putting files into our CM9 last night and the camera UI fired up for me but there was nothing on the viewfinder. i dont even remember what i did since i did a clean flash after
Click to expand...
Click to collapse
lol, try it again maybe? =)
First of all, take note that I ported this ROM myself with the help of proxuser’s guide, and therefore I included whatever I wanted in it as I did not intend to release it at first Because of this, Beats audio (by RockoDev) is included by default. I am crediting him now for his mod. This is based on IceColdSandwich by kajura and RD-MIUI by dekkyy. Any problems existing in IceColdSandwich will still exist here.
Features working
● GPS
● Flashlight
● Bluetooth
● HW Acceleration
● Mobile Data & Phone & Microphone
● High/Low Quality YouTube / Netflix / Hulu video
● Front Camera preview (may be inverted though)
● Back Camera Preview & Flash
● Beats audio by Rockodev (thanks! )
● Almost everything else…
Bugs, known issues, not working
x Directional compass not showing on maps
x Camcorder not working
x No FM radio officially supported (It will work if you use Spirit FM radio app)
x Backlights of capacitive soft keys and rotating keys
x You tell me…
DOWNLOADS
Version 0.2: https://www.dropbox.com/s/8f05hgmoudy2u5a/vivo-MIUI-v02-signed.zip REUPLOADED! should work now.
md5sum: C9B774A7B5B53653CB6C8F44FF59ADB8
you might notice that the updater script still says Ice Cold Sandwich; that's because i haven't changed it yet lol. by the way, the beats does not appear in your status bar; it just enhances the sound (i think )
I may not update this often since I'm busy with exams and school I'm also new to porting, so if there are any developers willing to help me optimize/fix the bugs (like the backlights) in the ROM... Please click the 'thanks' button if you liked it!
reserved...
downloading! will let you know how it does later!
sure, thanks! it works on my phone (since it was intended for my personal use lol) so it should work... tell me if you find any bugs btw
am trying to install but I get an error.
It says: Error in "...../vivio-MIUI-v02-signed.zip" (status 6).
I did a full wipe.
that's funny... let me check out the file again.
EDIT: Oh, I realized there was an error. Let me re-upload my file again. Sorry ):
When you say the capacitive buttons aren't working, do you just mean the backlight or do the buttons themselves not function? I can make the fix if you are building from source, but I would assume not from your use of the word port?
l0st.prophet said:
when you say the capacitive buttons aren't working, do you just mean the backlight or do the buttons themselves not function? I can make the fix if you are building from source, but I would assume not from your use of the word port?
Click to expand...
Click to collapse
Just the back light. When autobrightness is on the backlights turn off. If autobrightness is off then the lights are on for a while before turning off and i'm reuploading the file now... and yes, i did not build from source... is there any way to fix it without doing so?
Can I ask why you used the DHD as a base instead of the Inc 2? The Inc 2 is almost identical to our device (bar the CDMA radio)
l0st.prophet said:
Can I ask why you used the DHD as a base instead of the Inc 2? The Inc 2 is almost identical to our device (bar the CDMA radio)
Click to expand...
Click to collapse
Well... honestly, i didn't think of it. Shall I try porting it from miui.us of the Incredible 2 to see if the backlight works...
yongwen1 said:
Well... honestly, i didn't think of it. Shall I try porting it from miui.us of the Incredible 2 to see if the backlight works...
Click to expand...
Click to collapse
Yeah that would be awesome
Sent from my Incredible S using XDA
incrediblealex said:
Yeah that would be awesome
Sent from my Incredible S using XDA
Click to expand...
Click to collapse
Haha, shall do it tomorrow then. It's close to midnight here, so I'll probably go off now. I may upload it tomorrow night if I have the time to port lol.
I would give it a go, can't hurt. To be honest you should just be able to pair up the vivow ROM with a vivo kernel and change some telephony files et voila it should work, but I have a nagging feeling there is something in surfaceflinger that is different. Try porting it using proxuser's guide first off, see how that pans out. I'm not actually rooted myself as I have only just got my device back from warranty repair, but I will be happy to pitch in with whatever I can.
I will have to dig out my XTC clip and get back into the swing of things soon, I am getting the itch for flashing!
Haha, I could try that method actually proxuser's guide isn't 100% for all phones, so I have to troubleshoot it quite a bit and add permissions and stuff. That may take up time... Oh, on a side note, could you point me in a direction to build a ROM from scratch? I may try to build from scratch when I have the time, just for the fun of it
Downloading it, will let you know.
Sent from my Incredible S
Thanks for giving me something new to flash!
Looking forward to seeing the next builds hopefully that'll iron out a few of the little creases.
Good work
Finally
___________________________________
Device: HTC Incredible S (IncS)
Status: S-OFF - ENG Hboot
Rom: Virtuous Affinity v2.05.0
Android for life! <3
Very nice work!!
Not working
stop at icecold sandwich screen !!!
For me it works now!
And I have to say that it's really awesome!