FORUMS

[Dev] ICS Camera Driver Development

336 posts
Thanks Meter: 426
 
By zivan56, Senior Member on 6th December 2011, 08:12 PM
Post Reply Email Thread
Due to the change in ICS that requires moving the camera driver from libcamera to libhardware (like GPS and other devices for Gingerbread), a new driver has to be written.

The problem with this is that many data structures have changed. I couldn't get a single one to compile with the ICS SDK. There are many fundamental changes in the way memory is shared for preview/pictures/video, so that will need to be addressed. I have addressed picture only functionality in the skeleton driver, which will show how to transfer a picture back to the HAL.


ICS Camera Driver Overview

The driver seems to be very generic to most Qualcomm SoCs, so either approach should work for many other devices.

New Driver

See CameraHal_Module.cpp from the ICS source code to see what functions needs to be implemented. It needs to be placed in /system/lib/hw/camera.<target_name_in_build.prop>.so and have the struct "camera_module_t HAL_MODULE_INFO_SYM" inside the code, which the HAL looks for before loading. Once it is loaded, you must implement a few dozen functions to get it to work.


Old Driver

The old drivers primary interface with Android is through libcamera. This loads liboemcamera, which sends commands to the camera kernel driver and the Snapdragon DSP. Liboemcamera is a propriatary library with no documentation apart from the source for QualcommCameraHardware.cpp (which compiles to libcamera.so). The actual Linux kernel module is just a simple I2C bridge to control the camera, and provides no real interface.

Current code/skeleton driver available:
http://forum.xda-developers.com/show...7&postcount=17

Please do not comment in this thread unless you are able to contribute to the actual development process.
The Following 91 Users Say Thank You to zivan56 For This Useful Post: [ View ] Gift zivan56 Ad-Free
7th December 2011, 02:58 PM |#2  
KrewsialNL's Avatar
Senior Member
Flag Bucharest, Romania
Thanks Meter: 392
 
More
Please keep this DEV only!

Thank you.
The Following 17 Users Say Thank You to KrewsialNL For This Useful Post: [ View ] Gift KrewsialNL Ad-Free
8th December 2011, 12:27 AM |#3  
Senior Member
Thanks Meter: 225
 
Donate to Me
More
If you're having a problem with the autolocks not releasing when needed, just do the locking manually. It's definitely tedious, but doable. I would guess, however, it's going to be easier in the long run to just implement a proper CameraHal module. If structures that you're relying on have changed... it's almost certainly better to rewrite from scratch.
The Following 2 Users Say Thank You to blarfiejandro For This Useful Post: [ View ] Gift blarfiejandro Ad-Free
8th December 2011, 02:26 AM |#4  
OP Senior Member
Flag Vancouver, BC
Thanks Meter: 426
 
Donate to Me
More
Quote:
Originally Posted by blarfiejandro

If you're having a problem with the autolocks not releasing when needed, just do the locking manually. It's definitely tedious, but doable. I would guess, however, it's going to be easier in the long run to just implement a proper CameraHal module. If structures that you're relying on have changed... it's almost certainly better to rewrite from scratch.

Unfortunately, I cannot recompile it with the current ICS source, as the structures the module uses have changed significantly. I could get the 2.3 source and compile against that, but then I might as well just re-write it as you have suggested.
Re-writing it based off of QualcommCameraHardware.cpp will involve the exact same hurdles. The previous driver (libcamera.so, which is compiled from QualcommCameraHardware.cpp) supplied only some functionality to Android, and passed numerous others to liboemcamera.so (completely closed source) via the same dlsym's. So there still wouldn't be a proper driver, just one less layer wrapper.

Ultimately, the only solution looks to be just to use the very core initialization methods from libcamera and find the proper ioctl calls to /dev/msm_camera/control0
I have tried to do that earlier, but liboemcamera.so has callbacks to libcamera.so (which may be passed back again to libcameraservice in Android), so its going to take some reverse engineering to figure out out.

I have been working on a skeleton camera HAL driver, but all callbacks to Android cause libcameraservice to crash (like autofocus finished event). Perhaps its an issue of the libcameraservice.so being distributed with the roms here, I will try it on an emulator.
The Following 8 Users Say Thank You to zivan56 For This Useful Post: [ View ] Gift zivan56 Ad-Free
8th December 2011, 03:39 AM |#5  
Senior Member
Thanks Meter: 225
 
Donate to Me
More
Quote:
Originally Posted by zivan56

Unfortunately, I cannot recompile it with the current ICS source, as the structures the module uses have changed significantly. I could get the 2.3 source and compile against that, but then I might as well just re-write it as you have suggested.
Re-writing it based off of QualcommCameraHardware.cpp will involve the exact same hurdles. The previous driver (libcamera.so, which is compiled from QualcommCameraHardware.cpp) supplied only some functionality to Android, and passed numerous others to liboemcamera.so (completely closed source) via the same dlsym's. So there still wouldn't be a proper driver, just one less layer wrapper.

Ultimately, the only solution looks to be just to use the very core initialization methods from libcamera and find the proper ioctl calls to /dev/msm_camera/control0
I have tried to do that earlier, but liboemcamera.so has callbacks to libcamera.so (which may be passed back again to libcameraservice in Android), so its going to take some reverse engineering to figure out out.

I have been working on a skeleton camera HAL driver, but all callbacks to Android cause libcameraservice to crash (like autofocus finished event). Perhaps its an issue of the libcameraservice.so being distributed with the roms here, I will try it on an emulator.

With the Optimus V, at least, there's a lot of logic in liboemcamera such that any IOCTLs you call on the device will more or less get ignored unless they're what liboemcamera is expecting. I wouldn't spend a lot of time trying to preserve the 2.3 shim.
The Following User Says Thank You to blarfiejandro For This Useful Post: [ View ] Gift blarfiejandro Ad-Free
8th December 2011, 03:53 AM |#6  
OP Senior Member
Flag Vancouver, BC
Thanks Meter: 426
 
Donate to Me
More
Quote:
Originally Posted by blarfiejandro

With the Optimus V, at least, there's a lot of logic in liboemcamera such that any IOCTLs you call on the device will more or less get ignored unless they're what liboemcamera is expecting. I wouldn't spend a lot of time trying to preserve the 2.3 shim.

So that pretty much only leaves direct calls to liboemcamera basically. I don't see any easy way duplicate liboemcameras functionality, as it does lots of non-camera related hardware setup having to do with the DSP.
It might be easier to backport the old camera library instead to ICS if liboemcamera cannot be used.
The Following User Says Thank You to zivan56 For This Useful Post: [ View ] Gift zivan56 Ad-Free
8th December 2011, 04:33 AM |#7  
Visentinel's Avatar
Senior Member
Flag Washington
Thanks Meter: 158
 
More
Is it an option to simply port the gingerbread camera related AOSP code into use for ICS that way there is no trouble with the camera.

Sent from my HTC HD2 using Tapatalk
The Following User Says Thank You to Visentinel For This Useful Post: [ View ] Gift Visentinel Ad-Free
8th December 2011, 11:42 PM |#8  
OP Senior Member
Flag Vancouver, BC
Thanks Meter: 426
 
Donate to Me
More
Its an option. The camera API presented to apps themselves doesn't appear to have changed, so it shouldn't affect the functionality of them. Hopefully only libcameraservice needs to be changed.
I will be giving calling liboemcamera a go again before trying that.
The Following 4 Users Say Thank You to zivan56 For This Useful Post: [ View ] Gift zivan56 Ad-Free
9th December 2011, 08:14 AM |#9  
OP Senior Member
Flag Vancouver, BC
Thanks Meter: 426
 
Donate to Me
More
Just a small update (no progress on the HD2 itself)

I have a partially complete skeleton HAL driver written dealing with taking images (not panorama or video). I figured out how to deal with the various callbacks, and now have most major events handled (auto focus, take picture, transfer picture to Android)...it even returns a fake image to test memory operations. Will post it later if anybody is interested.
The Following 24 Users Say Thank You to zivan56 For This Useful Post: [ View ] Gift zivan56 Ad-Free
10th December 2011, 06:33 AM |#10  
OP Senior Member
Flag Vancouver, BC
Thanks Meter: 426
 
Donate to Me
More
update: managed to get the camera HAL to negotiate the settings with the camera app and HD2 (i.e picture size, saturation, etc) and init the hardware. Now I am struggling with the preview stuff.
Seeing this error:

E/mm-camera 8x vfe( 69): vfe_util_updaterollofftbl: sensor doesn't support rolloff correction by VFE

When it tries to register memory for the camera to put images into. I will have to look through the kernel source and see what its tripping up on.
The Following 20 Users Say Thank You to zivan56 For This Useful Post: [ View ] Gift zivan56 Ad-Free
11th December 2011, 07:21 AM |#11  
OP Senior Member
Flag Vancouver, BC
Thanks Meter: 426
 
Donate to Me
More
Next issue is I need /dev/pmem_smipool . Only some kernels provide this, so I will have to look for one that supports it.
The Following 12 Users Say Thank You to zivan56 For This Useful Post: [ View ] Gift zivan56 Ad-Free
Post Reply Subscribe to Thread

Tags
camera, hd2, ics

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes