Jump to content

kernel 2.6.32


Guest pier11

Recommended Posts

If building older interface - 7x0x - msm_v4l2.c should not participate. See .29 media/video/msm/Makefile

I know, so I just removed it. Kernel builds fine then. Combined zImage with pulse-uk2011 ramdisk, boots fine, sound working.

But video playback doesn't work at all.

I think for effectively removing v4l2, other parts of the kernel might require adjustments too. I'll search .29 kernel how v4l2 gets disabled there. Must be tied to CONFIG_MACH_MSM7201A_SURF there...

Hm... just thinking.. For HTC, people need to disable v4l2 in combination with our processor. Huawei makes some extra kernel adjustments for their 7200a devices, solely to make the camera work. At the same time, they have the ascend, pulse mini and the u8150, where they update camera drivers to libqcamera which uses v4l2, even in eclair. It would have been absolutely no extra effort for them to just do the same for the pulse. If it only was possible. I am beginning to believe that what we experience isn't some kind of kernel porting issue. I think it's just because using this kind of driver architecture is impossible on our msm7200a.

Edited by dr.flo
Link to comment
Share on other sites

... Kernel builds fine then. Combined zImage with pulse-uk2011 ramdisk, boots fine, sound working.

But video playback doesn't work at all.

I think for effectively removing v4l2, other parts of the kernel might require adjustments too. I'll search .29 kernel how v4l2 gets disabled there. Must be tied to CONFIG_MACH_MSM7201A_SURF there...

it'd be good to figure how to fix video issue with older interface/libs. This doesn't have any potential architecture issues...

May be it'll help in the end to our .32 native camera interface...

Link to comment
Share on other sites

... Kernel builds fine then. Combined zImage with pulse-uk2011 ramdisk, boots fine, sound working.

But video playback doesn't work at all.

Did the same - used /7x0x folder from .29 plus couple of camera headers from there. Used cm6.1 as a rom with ramdisk from it.

Communication goes to camera, but no preview. It crashes then entire system to reboot.

But previously recorded video plays. But it is black and white. Very strange. (It played in color with .29 kernel with which it were recorded.)

dmesg stuck here:

<6>[1931, Binder Thread #] [ 288.456388] ov3647.c: ov3647_i2c_write(): saddr=0x48, reg=0x1, value=0

<6>[1931, Binder Thread #] [ 288.456734] ov3647.c: ov3647_write_exp_gain,gain=0

<6>[1931, Binder Thread #] [ 288.457463] [adsp.c:msm_adsp_enable] enable 'QCAMTASK'state[0] id[17227151]

<6>[359, kadspd] [ 288.462391] [adsp.c:handle_adsp_rtos_mtoa_app] module QCAMTASK: READY

<3>[1931, Binder Thread #] [ 293.454496] [adsp.c:__msm_adsp_write] module VFETASK not enabled before write

<3>[1931, Binder Thread #] [ 294.451513] adsp: module 'VFETASK' write wait for enabled timed out

guessing it wants pairing qdsp_7200A

Edited by pier11
Link to comment
Share on other sites

Added qdsp_7200A:

- no sound;

- E/QualcommCameraHardware( 1243): interface_init: msm_camera opened failed!

- previously recorded video doesn't play - "Sorry, this video cannot be played."

----------------------

Incidentally installed Eclair's qdsp (wanted Froyo's :) ) from Code Aurora. The same behavior as above.

Edited by pier11
Link to comment
Share on other sites

Did the same - used /7x0x folder from .29 plus couple of camera headers from there. Used cm6.1 as a rom with ramdisk from it.

Communication goes to camera, but no preview. It crashes then entire system to reboot.

But previously recorded video plays. But it is black and white. Very strange. (It played in color with .29 kernel with which it were recorded.)

dmesg stuck here:

<6>[1931, Binder Thread #] [ 288.456388] ov3647.c: ov3647_i2c_write(): saddr=0x48, reg=0x1, value=0

<6>[1931, Binder Thread #] [ 288.456734] ov3647.c: ov3647_write_exp_gain,gain=0

<6>[1931, Binder Thread #] [ 288.457463] [adsp.c:msm_adsp_enable] enable 'QCAMTASK'state[0] id[17227151]

<6>[359, kadspd] [ 288.462391] [adsp.c:handle_adsp_rtos_mtoa_app] module QCAMTASK: READY

<3>[1931, Binder Thread #] [ 293.454496] [adsp.c:__msm_adsp_write] module VFETASK not enabled before write

<3>[1931, Binder Thread #] [ 294.451513] adsp: module 'VFETASK' write wait for enabled timed out

Tested with OpenEVE .32 qdsp. Exactly as above. (I.e. as with our stock .32 dsp)

Also tested with qdsp from Code Aurora's Froyo (tag M76XXTSNCJNLYA6010 - closest to our .32 kernel). The same as above.

Made a test with qdsp from Code Aurora's Froyo (tag M76XXTSNCJNLYA60401022 - September 28, 2011 - a year+ newer than above). The same as above.

Edited by pier11
Link to comment
Share on other sites

What look suspicious to me is dsp and it's audio in experiments. Why older dsp code doesn't produce any sound. And vice versa - why .32 dsp doesn't work on .29 kernel, all the rest equal. Same hardware, same radio processor.

Might be make sense to try to merge older dsp to the new one piece by piece and see at what point it breaks. To spot difference. That may point to corresponding difference in .32

--

.32 kernel for some strange reason also plays prerecorded video in black and white. The video was recorded from camera on the same set up but .29 kernel... dsp?

Edited by pier11
Link to comment
Share on other sites

Guest dejavu-8

expensive pier 11! Could you put a stable firmware and kernel with the latest changes. I would be very grateful . thank you

Edited by dejavu-8
Link to comment
Share on other sites

BREAKING NEWS:

I'm getting continuous preview (I.e. not freezing). I can also take picture!

Well, yes, it's older api/libs, but on .32 kernel.

Preview is in black and white. But any video playback is in black and white for some reason. But picture taken have normal colors!

Proper port of qdsp_7200A (yet unfinished) helped that. Stock qdsp from .32 could not make it.

Link to comment
Share on other sites

BREAKING NEWS:

I'm getting continuous preview (I.e. not freezing). I can also take picture!

Well, yes, it's older api/libs, but on .32 kernel.

Preview is in black and white. But any video playback is in black and white for some reason. But picture taken have normal colors!

Proper port of qdsp_7200A (yet unfinished) helped that. Stock qdsp from .32 could not make it.

Sorry for not responding during the day - I was away...

This is really great news! What's your test environment (CM6 I would guess)?

This may lead the way to better understand where it breaks. Does sound work with this ported qdsp?

I think the black&white issue could be fixed later. On some other thread I read about black&white instead of color video, this was just because of some broken default saturation/contrast settings.

Interesting that it needed so many trials to implant qdsp_7200A into .32, what was the trick that did it for you?

Link to comment
Share on other sites

Sorry for not responding during the day - I was away...

This is really great news! What's your test environment (CM6 I would guess)?

This may lead the way to better understand where it breaks. Does sound work with this ported qdsp?

I think the black&white issue could be fixed later. On some other thread I read about black&white instead of color video, this was just because of some broken default saturation/contrast settings.

Interesting that it needed so many trials to implant qdsp_7200A into .32, what was the trick that did it for you?

Sound works.

Yes - it's our hybrid - CM6.1

Two things made it working:

- driver name in adsp.c - msm_adsp_driver_name (looks something - maybe lib in user space - expected it no be named differently on Froyo than it were in Eclair). That's why stock .32 dsp gave sound but qdsp_7200A didn't. That gave sound but changed not much compared to .32 native version.

- last pieces that made difference - where I implanted (unmodified actually):

adsp_video_verify_cmd.c

adsp_videoenc_verify_cmd.c

adsp_driver.c  

Link to comment
Share on other sites

The fact that we now have a variant of kernel .32 that talks (almost) correctly to our old camera libs, opens another interesting field of research:

I'm currently looking into what prevents our pulse native eclair camera libs from working normally in froyo (not yet gingerbread)

CM6 uses this BOARD_USES_ECLAIR_LIBCAMERA hack to make things work. From what I know this hack merges libcamera_client.so and libsurfaceflinger_client.so back into libui.so (as it was in eclair, the code of libui.so was split up into separate libs in froyo); therefore, all other CM6 rom binaries that refer any of these libs also need to be patched. This is no good solution, and it doesn't work with CM7 anyways.

I plan to use a stock non CM6 froyo rom (e.g. your u8150 froyo reference rom) and make pulses eclair libs work there without BOARD_USES_ECLAIR_LIBCAMERA, by coding a small helper library that provides the missing functions (and simply forwards them to the libs where they reside now). This would enable our libcamera.so to integrate cleanly into froyo without touching any of froyo's binaries.

Since the BOARD_USES_ECLAIR_LIBCAMERA hack works on froyo, I expect the wrapper lib to work as well, but with the benefit that it's a cleaner solution. In the end, if we are very lucky, it will make our libcamera.so so much froyo compatible that it even might work in gingerbread with BOARD_USE_FROYO_LIBCAMERA.

But for all this, I need our classic camera interface to work in kernel .32, because u8150 reference rom doesn't like kernel .29...

A good thing that you are currently building said kernel. Could you prepare a patch for this once it is settled...?

Link to comment
Share on other sites

I plan to use a stock non CM6 froyo rom (e.g. your u8150 froyo reference rom) and make pulses eclair libs work there without BOARD_USES_ECLAIR_LIBCAMERA, by coding a small helper library that provides the missing functions (and simply forwards them to the libs where they reside now). This would enable our libcamera.so to integrate cleanly into froyo without touching any of froyo's binaries.

This sound very right to me. Wondering why nobody did that yet...

A good thing that you are currently building said kernel. Could you prepare a patch for this once it is settled...?

sure

Link to comment
Share on other sites

Guest anarkill

Please build the CM 7.1 ROM with new kernel .32! I think many people use CM 7.1 and always wanted to get the camera back in any condition. Please!

P.S sorry for bad English.

Edited by anarkill
Link to comment
Share on other sites

This sound very right to me. Wondering why nobody did that yet...

I can just guess...

Maybe someone tried but it didn't work out... but in theory it should at least work for froyo.

The other reason might simply be that once BOARD_USES_ECLAIR_LIBCAMERA was "invented", there was no need anymore to do this. And yet another reason is that to make libcamera.so load the helper lib, libcamera.so must the tweaked a little using a hex editor (add extra dependency). This would have to be done for all different libcamera.so's that should be supported, whereas BOARD_USES_ECLAIR_LIBCAMERA only has to be introduced once. And for CM6 it works.

I think I'll need 2-4 evenings for the helper lib, and then we'll know more... :)

Link to comment
Share on other sites

Please build the CM 7.1 ROM with new kernel .32! I think many people use CM 7.1 and always wanted to get the camera back in any condition. Please!

There is not yet any condition of camera with gingerbread! Nothing new here. Just research to better understand where the problem resides. As of now, no one can guarantee that camera will ever work in CM7. Be patient...

Link to comment
Share on other sites

A good thing that you are currently building said kernel. Could you prepare a patch for this once it is settled...?

Here's the patch enabling qdsp5_7200A from pulse's .29 kernel on .32 kernel.

It makes .32 kernel compatible with older camera libs known to work.

Semi-manual process.

1. Take from pulse's .29 source and replace/add the following folders/file:

arch/arm/mach-msm/include/mach/msm_adsp.h

arch/arm/mach-msm/include/mach/qdsp5/

arch/arm/mach-msm/qdsp5_7200A/
2. Apply two patches attached. 3. in .config:
# CONFIG_MSM_ADSP is not set

CONFIG_MSM_7200A_ADSP=y

qdsp5_7200A.u8150.patch.zip

Link to comment
Share on other sites

thanks for the patch info. I'll check out a new copy of the kernel from the repo and patch that, just to make sure nothing left over from old experiments.

But, we forgot, I also need to change camera API, not just qdsp.

Did the same - used /7x0x folder from .29 plus couple of camera headers from there.

Which were these (couple of headers)? Just

include/media/msm_camera.h

arch/arm/mach-msm/include/mach/camera.h

or additional files...?

edit: by the way: what happens when you use just qdsp5_7200A but new camera API? Can u8150-froyo open the camera?

Edited by dr.flo
Link to comment
Share on other sites

I think you are correct about the headers. Away from PC in the moment.

I have not experimented other than with cm6 yet...

EDIT:

checked, correct, that two headers.

here is patch for drivers/media/video/msm/Makefile

Edited by pier11
Link to comment
Share on other sites

Tested on stock u8220 (Pulse UK 2010) rom:

- Sound works.

- Video playback doesn't due to

E/copybit ( 1259): copyBits failed

- thus to camera preview.

- Takes pictures just fine.

- Front camera works (the same fashion as the main one - without preview but taking pictures).

Guessing copyBits is kernel specific stuff (I saw user space lib if I remember correctly), so replacing it might help.

Link to comment
Share on other sites

Out of curiosity, is it possible to make only the front camera working, on any rom and any kernel?

Cause if it is and it's the only one, wouldn't that make video calling apps (such as fring for example) work with our phones?

Just an idea, sorry for the off topic.

Link to comment
Share on other sites

Out of curiosity, is it possible to make only the front camera working, on any rom and any kernel?

Cause if it is and it's the only one, wouldn't that make video calling apps (such as fring for example) work with our phones?

Just an idea, sorry for the off topic.

I don't know definitive answer, but as an another idea - try to compile .29 kernel with only front camera - ov7690

Link to comment
Share on other sites

by the way: what happens when you use just qdsp5_7200A but new camera API? Can u8150-froyo open the camera?

tested on u8150-froyo rom.

new camera interface/old dsp

- video playback doesn't work

- camera app waits for something

- thus can't take picture.

- the same with sound as before - "controlled noise".

Seem froyo libs didn't like older dsp. But I think we should find what exactly made older dsp work on CM6 and try to patch .32 dsp with that...

----

Now goes CM7 hybrid... (your cm7rc + ascend libs)

- sound works;

- video playback works in color;

- camera preview doesn't start - consistent with u8150 above.

Edited by pier11
Link to comment
Share on other sites

Out of curiosity, is it possible to make only the front camera working, on any rom and any kernel?

Cause if it is and it's the only one, wouldn't that make video calling apps (such as fring for example) work with our phones?

Just an idea, sorry for the off topic.

What exactly is the problem with these apps?

1) they "work" but video is taken from the back camera, and thus it's not usable

2) they don't find any camera

If it's just 1), the solution (for UK 2.1 roms + .29 kernel) could possibly be simple. I could just patch the kernel to swap 1st and 2nd camera devices. Then the stock camera app would still allow to choose camera, but all apps that can't manually select the camera, should be forced to use front camera instead of back camera.

So if your problem is of type 1 and you are willing to try this on an official eclair 2.1 rom, I could prepare a patched kernel for you.

Edited by dr.flo
Link to comment
Share on other sites

Tested on stock u8220 (Pulse UK 2010) rom:

- Sound works.

- Video playback doesn't due to

E/copybit ( 1259): copyBits failed

- thus to camera preview.

- Takes pictures just fine.

- Front camera works (the same fashion as the main one - without preview but taking pictures).

Guessing copyBits is kernel specific stuff (I saw user space lib if I remember correctly), so replacing it might help.

Have to take my hat off to you guys - didn't think you would get this far with camera!

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.