Related
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/showpost.php?p=20281617&postcount=17
Please do not comment in this thread unless you are able to contribute to the actual development process.
Please keep this DEV only!
Thank you.
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.
blarfiejandro said:
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.
Click to expand...
Click to collapse
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.
zivan56 said:
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.
Click to expand...
Click to collapse
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.
blarfiejandro said:
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.
Click to expand...
Click to collapse
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.
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
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.
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.
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.
Next issue is I need /dev/pmem_smipool . Only some kernels provide this, so I will have to look for one that supports it.
Great work! I know this is developer only thread but I want to help. I do not know how to code however I can test.
Sent from my NexusHD2 using xda premium
I'm afraid unless you know how the pmem stuff works, you can't really.
The main problem now is that the driver (based off QualcommCameraHardware.cpp) and the kernel don't agree on where the shared memory is located (one of MSM_PMEM_OUTPUT1, MSM_PMEM_OUTPUT2 or MSM_PMEM_RAW_MAINIMG, MSM_PMEM_PREVIEW).
Now this depends on the 720p option being enabled/disabled in the kernel (which strangely enough, doesn't actually give 720p support for the HD2).
This is where it errors out:
E/mm-camera 8x-vfe snapshot( 69): vfe_snapshot_raw_axi_init: failed
(message comes from liboemcamera.so)
Kernel reports this:
msm_frame_axi_cfg 1293: pmem region lookup error
So it never transfers the picture/video/preview frames to the shared memory region
Likewise, the QSD8250 CPU has some very unique settings that other MSM devices do not. For example, its preview mode is just video capture mode. Whereas others have a dedicated preview mode.
So far what works:
- Init sensor, set effects, zoom, contrast, etc (and adjust on the fly)
- Take JPEG picture process and transfer to camera app (but only returns solid green due to the kernel not copying the picture into the proper pmem)
- Set video mode
zivan56 said:
MSM_PMEM_OUTPUT1, MSM_PMEM_OUTPUT2 or MSM_PMEM_RAW_MAINIMG, MSM_PMEM_PREVIEW
Click to expand...
Click to collapse
Would it be possible to physically assign a memory address for these variables within the kernal? I understand theirs probably not much I can do, but I'm more than happy to if something comes up I can do. (I can't wait to take programming in school soon)
Sent from my NexusHD2 using xda premium
If your finding yourself getting stuck at any point the best person I can recommend from past knowledge would be XDA member DZO (Martin) who had done alot of sensational work on porting android to nand onto a number of QVGA WinMo devices i.e. Kaiser, vogue, polaris... rewriting many of the drivers himself from scratch.
I hope he is still active here on XDA, his work will be greatly remembered, even more so for myself as I used to own a HTC Kaiser in the past...
If your interested here's a bit about him from an XDA Interview: http://www.xda-developers.com/android/developer-interview-dzo/
XDA Member Profile: http://forum.xda-developers.com/member.php?u=917443
(Looks like he's still active too xD)
Best Regards,
ST1Cl<^^aN
kylew1212 said:
Would it be possible to physically assign a memory address for these variables within the kernal? I understand theirs probably not much I can do, but I'm more than happy to if something comes up I can do. (I can't wait to take programming in school soon)
Sent from my NexusHD2 using xda premium
Click to expand...
Click to collapse
Unfortunately, it doesn't look possible. The kernel driver (msm_camera.c) needs a special type of memory that the DSP can write to. The userspace driver tells the kernel to set up the memory and passes the details back to the kernel driver which tells the hardware to write to this special shared memory. I can copy the data from this buffer to the camera HAL, that works fine...but there is no data in the memory obviously.
Stickman89 said:
If your finding yourself getting stuck at any point the best person I can recommend from past knowledge would be XDA member DZO (Martin) who had done alot of sensational work on porting android to nand onto a number of QVGA WinMo devices i.e. Kaiser, vogue, polaris... rewriting many of the drivers himself from scratch.
I hope he is still active here on XDA, his work will be greatly remembered, even more so for myself as I used to own a HTC Kaiser in the past...
If your interested here's a bit about him from an XDA Interview: http://www.xda-developers.com/android/developer-interview-dzo/
XDA Member Profile: http://forum.xda-developers.com/member.php?u=917443
(Looks like he's still active too xD)
Best Regards,
ST1Cl<^^aN
Click to expand...
Click to collapse
Thanks for the contact. As long as they are Qualcomm MSM/QSD devices, it should be really similar.
Since there were a number of requests for the current code, I am releasing the code for two things:
1. Skeleton.zip - A skeleton HAL which shows you how to do simple image transfers back to the HAL/setting negotiation. This should help with developing drivers for any device or if someone wants to start the HD2 driver from scratch. It will also complete the process of picture transfer back to the camera HAL (with a fixed picture of course)
2. libcamera3.zip - Progress so far on the HD2 driver. It will init the sensor, change/negotiate settings with the HAL.
It also implements notify/data callbacks which have changed significantly with ICS. There are scripts in there to help with getting the driver to the HD2 and chmod the devices so you dont have permission issues.
I used tytung's latest ICS build and the HD2 AOSP dev environment (http://forum.xda-developers.com/showthread.php?t=1361859) see post #3 how to set it up. You may need to pull binaries from the ICS build to the prebuilt folders in the SDK in order to link the driver properly.
The scripts assume the git repository above is in ~/ICS/ and the Android SDK (with adb) is in ~/android-sdk-linux/
Documentation is nonexistant, but it should be easy to figure out. I cannot help anyone with what QualcommCameraHardware.cpp does, I did not change it much apart from implementing the new callbacks and the ICS HAL wrapper.
I wont have much time to work on it, so hopefully someone else can get the ball rolling on getting the shared memory stuff to work properly. Likewise, set up a git repo somewhere for others to contribute.
thx
thanks for effort and work
how does the development continue ?
I am sure someone will pick it up. Its in the interest of owners of the Nexus One and a bunch of other Qualcomm Snapdragon based phone owners who want the camera working in ICS. If someone fixes the driver I was working on, it should support at least a couple more devices with very small changes in the code (or perhaps 1 driver that works on all of them by detecting the phone).
from ankuch ICS sd build: http://forum.xda-developers.com/showpost.php?p=20305195&postcount=677
ankuch said:
Yes. I got first image from camera
Click to expand...
Click to collapse
Edit: Sorry not a dev post
Just curious as everyone freaks out about cyanogenmod... what would be the benefit of running it over, say... Calkulin's rom? I have CM7/9 on my HP Touchpad, and I don't see anything major that differentiates it from normal android?
small and clean.
It's completely open-source (built off of the Android Open Source Project)
Many more options for customization
No need for "rooting"
Built-in theme manager
Consistent default user environment over multiple devices
There are many more of course, but those are some of my favorites. I mainly support it because I am a huge proponent of open-source software, and I enjoy the level of customization without "bloatware" from carriers or device manufacturers.
If you'd like to see a few more specific features, check out the wiki here: http://wiki.cyanogenmod.com/wiki/Features
While I admire the skill and time it takes the devs, I won't run the CM ROMs because it disables dialer codes, and if I want to update my PRL or baseband, I'm forced to install a different ROM to do so.
Sent from my SPH-D710 using XDA App
Im curently running jellybam 6.7 and i was wondering if anybody can give me as much info as possible on what exactly frameworks and dpi are and what exactly they do. Im also wondering about the kernals i kno there are other compatable kernals that could be flashed with jellybam but i honestly know nothing about them or wat it changrs. Im a noob to most of this and im just trying to make sure i completely avaoid bricking my phone. Any help or info would be much appreciated.
Sent from my SPH-L710 using xda app-developers app
Roni P. said:
Im curently running jellybam 6.7 and i was wondering if anybody can give me as much info as possible on what exactly frameworks and dpi are and what exactly they do. Im also wondering about the kernals i kno there are other compatable kernals that could be flashed with jellybam but i honestly know nothing about them or wat it changrs. Im a noob to most of this and im just trying to make sure i completely avaoid bricking my phone. Any help or info would be much appreciated.
Sent from my SPH-L710 using xda app-developers app
Click to expand...
Click to collapse
I have more experience with messing with DPIs than I do with kernels, so I'll let someone else answer your question about kernels.
DPI normally stands for Dots per Inch. When it comes to printer, the higher the dpi the smaller the dots and, therefore, the higher "resolution" you get. For Android, though, DPI talks more about the pixel density (I think it's Density Pixel Index, I could be wrong, though). If you really want to get into Android uses this value in their code, the first comment in this post does a good job (IMO) of showing where it comes into play. After all that, the basic correlation is this: lowering the DPI will shrink your icons/apps/etc and effect the way certain apps appear on your phone. The stock GS3 setting for DPI is 320.
The reason people (like myself, running 241 dpi) choose lower DPIs is that certain apps (like calendar, Hulu, Netflix, etc.) have better interfaces on tablets than they do on phones, so we want to "force" them to think our GS3 is a tablet. The "official" way of doing this is by modifying the build.prop file. There's a semi-guide here that you can follow. The main problem with changing this value is that the Google Play Store looks at it to verify your phone. If the phone type does not match the the DPI value, you won't be able to download any apps! There are various fixes to this, but my preferred choice is just to download and install a modified Play Store which allows multi-DPI. Here is the thread for the one that I use (see post #2 for downloads).
Some ROMs also allow you to change the DPI "on the fly" without having to modify the build.prop. I'm currently running LiquidSmooth and in my Settings --> Interface --> LCD Density looks like this. It also has steps that you need to take to make your Play Store work. Having the multi-DPI play store that I linked previously will prevent you from havign to do the "clean up" work, but it doesn't hurt to follow the steps.
Now that you know a bit more about that, there are ways to get the advantage of a lower DPI on certain apps without havinn to mess with the build.prop or a Multi-DPI play store. ParanoidAndroid is a ROM that has "per-app DPI settings" built into it. Some other ROMs have the "Xposed DPI application," which serves a similar purpose. Per-app DPI systems like these two can "force" any app to see your device at a DPI that is not the current System DPI. For instance, I can have my system DPI as standard (320), but when I run Hulu, it sees my device as 241 DPI, so the layout will be similar to what I would see on my tablet (which I prefer for Hulu). This is nice because if you mess up a setting for an app, you can just revert the changes and clear the app cache and it'll be good to go again.
Hopefully this is a good primer to see the purpose of DPI and how it's used to customize your experience with your phone.
Let me talk about frameworks and kernels now...
A kernel is the powerhouse of an OS altogether. It is this layer that provides all interfacing with hardware that the OS can then use to implement things like network toggles and such
Everything is defined in the kernel...if something is not defined there, then you cannot use it
This is the reason why building newer roms (from source and not yet supported officially) is difficult because you gotta build the kernel from the ground up. You gotta implement things like Wifi, Power management (voltages, CPU, and proper shutdown and booting up sequences), 4G (if applicable), and 3G
So in summary, the kernel is what provides the software (in this case the Android OS) access to hardware components through this intermediate layer
Now the reason people flash other kernels is because some may manage power better (resulting in better battery life), may implement more features (have more CPU governors or IO schedulers), or provide some extra quality (could be something important like 4G or something as aesthetic as enabling boot animations)
Now frameworks. Each proprietary interface has its own frameworks. AOSP is normally not mentioned when discussing frameworks because it is the "vanilla" or "stock" interface provided by google straight from the original AOSP source that all other proprietary frameworks are built on top of
HTC has its own interface, so does Motorola, Samsung, and LG
HTC's interface is called Sense, Samsungs is called Touchwiz and LG's is called LG UI (very creative, i know ), and i believe, but I may be mistaken, that Motorals interface is called MotoBlur
And each of these proprietary interfaces is primarily defined in the frameworks-res.apk and SystemUI.apk. It is these additions (addition being used in reference to what Google provides) that give each interface its unique spin on things. This is what causes the weather to animate on an HTC phone as soon as you unlock it, what gives the apps a different icon and more features, what changes the icons for the different things in the status bar, what shows recent apps and quicksettings when you slide down the status bar. In touchwiz its the same thing, different icons and other proprietary features like multiview and a more unique keyboard
Basically, the "frameworks" that you keep hearing about is what defines a proprietary interface. It is because of these interfaces that you cannot install proprietary apps or enable proprietary features on AOSP. These things are dependent on the frameworks of their respective interfaces and since AOSP has a different frameworks, then you'll just get FCs and such.
Now I'm not saying its impossible to port proprietary features over to AOSP. It can be done. But its extremely difficult because first you need to track down where exactly these features are defined, and then condense them into either a standalone app, or a series of standalone apps that will behave the same way.
Thanks guys... So now where does the exposed settings come into play? Is it honestly worth messing with or is going to open a whole new world like rooting rooting my phone? Lol
Sent from my SPH-L710 using xda app-developers app
Roni P. said:
Thanks guys... So now where does the exposed settings come into play? Is it honestly worth messing with or is going to open a whole new world like rooting rooting my phone? Lol
Sent from my SPH-L710 using xda app-developers app
Click to expand...
Click to collapse
I touched upon this in my reply.
Now that you know a bit more about that, there are ways to get the advantage of a lower DPI on certain apps without havinn to mess with the build.prop or a Multi-DPI play store. ParanoidAndroid is a ROM that has "per-app DPI settings" built into it. Some other ROMs have the "Xposed DPI application," which serves a similar purpose. Per-app DPI systems like these two can "force" any app to see your device at a DPI that is not the current System DPI. For instance, I can have my system DPI as standard (320), but when I run Hulu, it sees my device as 241 DPI, so the layout will be similar to what I would see on my tablet (which I prefer for Hulu). This is nice because if you mess up a setting for an app, you can just revert the changes and clear the app cache and it'll be good to go again.
Click to expand...
Click to collapse
So basically, the Xposed DPI application allows you to control the DPI on a per-app basis. You can tell Hulu to use 241 dpi and Netflix to use 190 DPI (or whatever you want), even if you have your phone's "default" to be the standard 320 DPI.
In terms of functionality, it'll affect different apps in different ways. A lot of the time, apps won't change at all. Some will stop working, so you'll just have to revert the settings and clear cache and you'll be good to go. It's really up to you which apps you want to modify. A lot of people don't mess with this stuff for fear of breaking things, but Xposed shouldn't have "lasting" effects.
Back when I was using ParanoidAndroid, I had toyed with the idea with creating a Thread in the General forum about which apps look best with modified DPIs. I eventually gave up the idea (was a huge effort while I was creating screenshots of each app before and after), but it might be good to start one up now that XPosed is being included in a lot more ROMs. Meh, maybe once I have a bit of free time.
Hi All,
I have been reading that a fully functional Sense rom is not possible, and it is about kernels or such, But I am having trouble understanding the real problem. I tried digging the site for the reason, but searching HTC and Sense in a mobile developer forum hardly filters any entry, so please help me understand.
I am thinking as 3 layered structure, Linux kernel in the middle, drivers at the bottom and AOSP with sense modifications at the top.
The problem I am having is, since the kernel is GPL, how come nobody was able to glue all of them together. I am assuming the top part has some non standart calls/interfaces with the kernel, but it must be open source, so what is the part that makes patching same interfaces/calls to another kernel impossible?
If the calls require driver changes(taking in to account nearly all drivers are proprietary) that means we need same hardware of a sense device, but it possible if hardwares match, right?
The real question, is it not possible technically, too hard to implement practically or just won't worth the effort?
enginmanap said:
but it possible if hardwares match, right?
Click to expand...
Click to collapse
There isn't a single HTC device with OMAP4 CPU to my knowledge.
Sent from Samsung Galaxy Nexus @ CM11
Suppose one has a small set of requirements for changes to make one's Nexus 7 useful for a particular requirement.
How does one go about finding the right modded kernel/rom combination for the job??
My current requirements are, as far as I can see from my initial considerations:
The OTG charging mod, i e it must be possible to charge the Nexus 7 2013 using high current while using the USB connector in OTG mode.
I need to be able to mount a large (32GB or more) NTFS or FAT32 USB stick inside the normal file system, so that any app can use the stick for file access and storage.
I need to be able to use a class compliant two-way record/play USB Audio Interface, and/or use something like the Audio Evolution Digital Audio Workstation app for field audio recording in pro quality, while simultaneously using a USB stick for storing the recorded audio.
SO, how would I go about finding workable kernel, rom and add-on-apps to enable this on the Nexus 7 2013 WiFi tablet?
The ElementalX kernel has OTG charging built in and will work with Ntfs/Fat32/exFat
Sent from my Nexus 7 using xda premium
rap3rman said:
The ElementalX kernel has OTG charging built in and will work with Ntfs/Fat32/exFat
Sent from my Nexus 7 using xda premium
Click to expand...
Click to collapse
Well, yes, that answers my current specific needs, possibly. Thank you!
(BTW what ROM would you recommend for use with the ElementalX kernel???)
However, what I asked was more about a general method of finding a kernel+rom suited to some random specific need.
Is there a list of what kernels and roms do? Is there some part of the XDA site where this kind of info can be found??
Is there some part of XDA or somewhere else where people test kernels+roms? To find limitations?
n3mmr said:
Well, yes, that answers my current specific needs, possibly. Thank you!
(BTW what ROM would you recommend for use with the ElementalX kernel???)
However, what I asked was more about a general method of finding a kernel+rom suited to some random specific need.
Is there a list of what kernels and roms do? Is there some part of the XDA site where this kind of info can be found??
Is there some part of XDA or somewhere else where people test kernels+roms? To find limitations?
Click to expand...
Click to collapse
As for the rom do you prefer speed or customisability?
If you mean how kernels perform with each rom you can find that in the Kernel's thread
http://forum.xda-developers.com/showthread.php?t=2389022
:good:
Each kernel has its own thread that tells exactly what it does and then users and the developer discuss all of it throughout the thread.
So you're saying there's NO rational way: You ALWAYS have to wade thru massive amounts of partly unrelated text, not all in any sort of reasonably obvious place or in any sort of rational structure.
Well.
Or ASK outright, and hope somebody just happens to have given the same question some thought recently??
Ah well. Forums, I guess.
n3mmr said:
So you're saying there's NO rational way: You ALWAYS have to wade thru massive amounts of partly unrelated text, not all in any sort of reasonably obvious place or in any sort of rational structure.
Well.
Or ASK outright, and hope somebody just happens to have given the same question some thought recently??
Ah well. Forums, I guess.
Click to expand...
Click to collapse
ElementalX has a caf kernel and an AOSP kernel. Thus you can use about any ROM you want with it just so you choose the correct corresponding kernel. There are a couple of lists that list many of the ROM's, kernels, recoveries etc. but there is no list that goes through each function of every ROM. That would be near impossible to keep up because devs change their builds all the time. AOSP might add or remove functions and now the devs have to work around it. There is just to much change to realistically keep a list like that and have it be accurate at all times.
Sent from my Nexus 7 Flo running CM 11 4.4.2 with ElementalX Kernel using XDA Premium 4 mobile app