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
Related
Please stay ON TOPIC to kernel DEV and missing code. Don't report every bug the Android build your using is having or it will be deleted as OFF TOPIC
As you all might be knowing that hd2 is pretty much a android native device now. Its just like any another snapdragon device. The current kernel code we are using in HD2 is pretty obsolete and missing a lot of things. It more like something working at its minimal efficiency. While i was porting over all the HD2 board files getting it on par with the other snapdragon devices I found out a lot of code was missing and some was obsolete. Eg. The gsensor code from microp was pretty minimal, a lot of things were missing in microp code. I suspect that it isnt the only code, a lot of bluetooth related stuff was missing and much more. I am not really gonna work on backporting the stuff to .32 kernel so i would like the kernel devs here to backport the stuff to the .32 kernel so a lot of bugs can be fixed and stuff can be made more stable until the .37 kernel is ready. All the commits can be found here
https://github.com/charansingh/cm-kernel/tree/master
There might be some bravo or passion instances in there cuz i am comparing the code with these two devices and taking what is necessary and sometimes i have to leave my work due to some other work and forget which file i was working on so would appreciate the more bugs.
Also Mods can we get this a sticky so we can track the progress here
Yap.. i'm not a really pro developer but i suspected those bugs before.. finally a real developer suspected that.. eager to see who's going to help fixing them
charnsingh_online said:
Also Mods can we get this a sticky so we can track the progress here
Click to expand...
Click to collapse
Ok sticky for the moment to see if it helps.
@charnsingh_online
I am really happy that you put so much power in this project big respect for that.
The reason for the missing code is because most of the drivers are reversed engineerd from winmo by cotulla. Wich make it possible to make working android parts but they don't work optimal by that. Also we miss some skilled active coders. After cotulla almost everything is created by markinus he did a incredible part big credit to him but looks like he isn't that active anymore..
Current development are mostly little things a guy who sees a little part from that and a little part from that like : you, tytung, darkstone, gauner,letama, the guy from the bluetooth fix.
We probaly don't have so much real kernel programmers because they buy a native linux / android phone.
The last two major things left with HD2 Android are buggy speakerphone and missing assisted-gps function.
Speakerphone mode is not usable because mic gain does not change when speakerphone is enabled. Info here:
http://forum.xda-developers.com/showpost.php?p=12698204&postcount=22
GPS works but without assistance so most locks take 1 minute instead of like 15 seconds. Info here: (please read all 25 pages)
http://forum.xda-developers.com/showthread.php?t=1008252
memin1857 said:
The last two major things left with HD2 Android are buggy speakerphone and missing assisted-gps function.
Speakerphone mode is not usable because mic gain does not change when speakerphone is enabled. Info here:
http://forum.xda-developers.com/showpost.php?p=12698204&postcount=22
GPS works but without assistance so most locks take 1 minute instead of like 15 seconds. Info here: (please read all 25 pages)
http://forum.xda-developers.com/showthread.php?t=1008252
Click to expand...
Click to collapse
actually i think the gpu drivers are kinda unstable when comparing to the performance of other phones that carry the similar gpu...
@charnsingh_online
Good start.
After reading the github commits, I still don't understand what kernel devs can do so far.
Just see the microp stuff I added to the file. Also I have updated the board files. See wats the difference between the files. A lot of updated code
hi charansingh,
i am willing to help, but i think it would be helpfull to define packets to take over.
By looking in the kernelsources it looks good to me, but i know from own expiriences with porting that i have to look deep...
best regards
trilu
charnsingh_online said:
Just see the microp stuff I added to the file. Also I have updated the board files. See wats the difference between the files. A lot of updated code
Click to expand...
Click to collapse
It's better to start/clone from pure CM 2.6.37 kernel, then add new commits when adding any new functions.
Would you please add a new commit when adding a new function?
Otherwise, it's very easy to lost the way in the source code.
A commit "Update some board files" doesn't tell the whole story. I want to know why to change.
Comparing the source code manually and guessing its function is not convenient for any kernel devs.
For me, I won't add any code in my 2.6.32 kernel until I know the meaning of the changes of the source code.
Thanks.
Ok I'll do it tomorrow n also maintain the list in the op
I may be wrong, but this thread is not supposed to become a bug fix request thread. It is aimed at developpers, so that they collaborate on a merging of HD2 specific stuff onto a cyanogen 2.6.37 kernel...
This would most likely result in the resolution of a lot of our issues, but in the mean time, [DEV] in the thread title means it is for devs only......
Keep this thread clean please.. there are only a select few devs who actually work on kernels around here. Let them use this as a way of communication to generate a complete kernel, then we can test it for bugs.
Very excited about the prospects of this, if you guys get a working kernel with all the new commits shoot it over and I'll test it out on one of my HD2's.
I looked pushed code and it's ok, at least for first few commits. But it needs some deep cleaning an optimization, also there is some bravo naming convention used in leo specific files. You should put this tree on gitorious so we can do more work on it, but anyway i will clone tree and do some cleaning and porting new stuff.
This could be of interest, and not too much off-topic.
This kernel: http://forum.xda-developers.com/showthread.php?t=966786
is being abandoned and it had some patches for performance that I think are valuable. It had linpack scores that can be achieved only with heavy overclocks on other kernels... The problem is, the source is being distributed by a .zip, no commits, nothing... the only way to get those would be to issue a diff with... something and guess where they are. Staying on topic, I've already adapted cm-kernel for another device so I think I'll be able to help when I get enough free time to spare.
D4rk50ul said:
Keep this thread clean please.. there are only a select few devs who actually work on kernels around here. Let them use this as a way of communication to generate a complete kernel, then we can test it for bugs.
Very excited about the prospects of this, if you guys get a working kernel with all the new commits shoot it over and I'll test it out on one of my HD2's.
Click to expand...
Click to collapse
Yes you are right. Unfortunately many threads like this one get's filled with off topic chatter, complaints etc. I will try to keep my eye on this thread so the dev's can communicate. If your not contributing to the DEV work on the HD2 kernel's, please don't post your wishes and thanks post as this will quickly clog up the thread. I'd hate to lose progress due to this. That's why many DEV's end up not using XDA and reverting to IRC only. Thanks
noellenchris
Hi,
Few days back there are some conversation about libsurfaceflinger.so for color banding issue http://forum.xda-developers.com/showthread.php?t=1012278 . Since Rom is changing continuesly with libs can we port the change for color issue.
HD2 GB-2.33-SENSE-2.1 LOCKSCREEN SENSE-3
tytung said:
It's better to start/clone from pure CM 2.6.37 kernel, then add new commits when adding any new functions.
Would you please add a new commit when adding a new function?
Otherwise, it's very easy to lost the way in the source code.
A commit "Update some board files" doesn't tell the whole story. I want to know why to change.
Comparing the source code manually and guessing its function is not convenient for any kernel devs.
For me, I won't add any code in my 2.6.32 kernel until I know the meaning of the changes of the source code.
Thanks.
Click to expand...
Click to collapse
tytung, has any1 of you done so? please let us know..
g30rg10u said:
tytung, has any1 of you done so? please let us know..
Click to expand...
Click to collapse
No, I didn't work on 2.6.37 kernel so far.
I didn't see that charnsingh_online added a TODO list in the OP.
Fried my laptop charger. New one on way. Hd2 arrived
--update4 feb 18 below: camera patch + WIFI dropped connection
Hi,
Sorry to post here, as new user I don't have access to the Android development board.
I have altered [ACL]'s latest kernel (2.6.27-46 git g6a073c7 from 2 feb) to support the Rhodium 100 camera. The update package and the diff are attached.
The change does essentially the same as an earlier change to Andoid SD posted by brinka123, but is implemented differently to prevent upstream rejection as happened to the patch by brinka123. The update package is the 2 feb update that [ACL] posted with the kernel replaced. Can someone can post this to the devel board? I'm looking for testers...
Thanks,
Eric.
--update1 (new user = no new post to devel board):
Thanks arrrghhh for moving my post here. Yes, the zip can be flashed from SD card from the boot menu.
[ACL], the changes apply to all MACH_TYPE_HTCRHODIUM machines (from mach-types.h), that includes all GSM Rhodium devices I believe. I don't know how to narrow that down to the 100 alone, aside from using a kernel boot parameter.
As for the intended scope for this change: most people reporting camera issues are rhod100 users, but I've seen posts from non-rhod100 users having occasional camera crashes. Because the patch targets the used frame rate it is likely that the camera hardware in most rhod100s - and some non-100's? - just can't handle the original framerate. So if there are non-rhod100 users having occasional camera crashes...
--update2
Changed patch to make it rhod100 specific using machine_variant_type. Thanks muziling. See attached zip and diff (postfixed _1). Non-rhod100 users with crashing camera's -if any- should use the original zip to test.
Please note that this patch does not include brinka123's change for low-light conditions. Didn't that one cause problems when zooming in? I can look into that change, but would like to separate it from this patch.
Next thing I want to do is look into the audio issue when using the cam - audio runs for 1 sec, then drops. I need to go into Android code for that*
I've worked hard this evening to compile OMGB with [ACL]'s device specific files (both github), but failed miserably. Looks like I'm missing the rhodium makefiles, any pointers?
I did manage to get 7.5 GB of sources on my PC, so I guess I'm at least halfway
*: while recording video logcat shows a happily recording cam and then suddenly:
V/Libacoustic-wince( 85): msm72xx_start_acoustic_setting
I/AudioHardwareMSM72XX_wince( 85): disabling volume method=AUDIO
V/Libacoustic-wince( 85): msm72xx_set_acoustic_table 256 0
V/Libacoustic-wince( 85): Use current device 13
-- update3
The attachment OMGB_2.6.27.46-01399-g6a073c7-rhod100camera_1.zip lacked matching kernel modules (no wifi, ...).
Corrected that by uploading attachment OMGB_2.6.27.46-01399-g6a073c7-rhod100camera_1a.zip
Note that this second update does nothing for rhod 2xx,3xx devices.
--update4
Camera:
Some people reported improved all-rhodium camera quality under low-light conditions using brinka123's changes. The change that is present in the attached patch does improve low-light image quality somewhat as it lowers the framerate, increasing the ccd integration time (1 frame + blanking). The remaining changes from brinka123 not included in the patch do not improve low-light image quality. These changes just limit the CCD integration time to one frame incl blanking, preventing hardware enforced framerate drop but delivering a darker picture with more noise. So I think the patch as-is is fine.
Wifi:
To properly debug camera audio issues I wanted a build environment using OMGB git + [ACL]'s device_htc_rhodium git. After a week of total war between me and the Android build system I have a working environment that results in a working phone. Had to create lots of Android makefiles from scratch to do that, and by accident it resulted in a phone that doesn't drop it's WIFI connection every now and then (Wifi icon turned gray 1-2 times a day, toggling wifi off/on reconnects). The difference with [ACL]'s build is not in the code, but somewhere in the makefiles + properties + different firmware files and is difficult to narrow down. If the WiFi issue I had is real and not something limited to my phone/access points I can look into this. Anyone with this problem?
Thanks mate, moved your thread to development.
Interested to hear how this pans out. I'm assuming RHOD100 users on OMGB can just flash that .zip via recovery?
ImTuxy said:
Hi,
Sorry to post here, as new user I don't have access to the Android development board.
I have altered [ACL]'s latest kernel (2.6.27-46 git g6a073c7 from 2 feb) to support the Rhodium 100 camera. The update package and the diff are attached.
The change does essentially the same as an earlier change to Andoid SD posted by brinka123, but is implemented differently to prevent upstream rejection as happened to the patch by brinka123. The update package is the 2 feb update that [ACL] posted with the kernel replaced. Can someone can post this to the devel board? I'm looking for testers...
Thanks,
Eric.
Click to expand...
Click to collapse
Hey dood. Lets get some rhod 100 folk to test this bad boy. We also need to make sure it doesnt break the other variants. I'm also going to send this to the kernel team so it can be analyzed for xdandroid as well. If this change is Rhod100 specific, then we need to change it so only rhod100 loads it.
ImTuxy said:
Hi,
Sorry to post here, as new user I don't have access to the Android development board.
I have altered [ACL]'s latest kernel (2.6.27-46 git g6a073c7 from 2 feb) to support the Rhodium 100 camera. The update package and the diff are attached.
The change does essentially the same as an earlier change to Andoid SD posted by brinka123, but is implemented differently to prevent upstream rejection as happened to the patch by brinka123. The update package is the 2 feb update that [ACL] posted with the kernel replaced. Can someone can post this to the devel board? I'm looking for testers...
Thanks,
Eric.
Click to expand...
Click to collapse
Great work, Eric. I have tested now cursorily and first observations are:
1. Camera works great including autofocus
2. Camcorder - videorecording works, but there is problem with recording audio. Recording approximately first 1 second and then silence.
I made 4 photos and 2 videos (30 second and 5 second) and this consumed 49% of my battery.
May I send you any logs or another help with testing?
Anyway many, many thanks to you!
Edit: After recording this kernel is sometimes spontaneously turns on the display including four buttons at bottom, in that moment the LED lights up in orange (wake) and immediately off again and the LED turns green (sleep). Display lights approx. 1 second.
[ACL] said:
Hey dood. Lets get some rhod 100 folk to test this bad boy. We also need to make sure it doesnt break the other variants. I'm also going to send this to the kernel team so it can be analyzed for xdandroid as well. If this change is Rhod100 specific, then we need to change it so only rhod100 loads it.
Click to expand...
Click to collapse
I was under the impression that the 'improvements' would actually help all RHOD's. I know when I ran brinka's kernel for testing, the low-light performance did seem better.
So unless it outright breaks all other RHOD's, I'd say it should be applied to all RHOD's.
milda25 said:
Great work, Eric. I have tested now cursorily and first observations are:
1. Camera works great including autofocus
2. Camcorder - videorecording works, but there is problem with recording audio. Recording approximately first 1 second and then silence.
I made 4 photos and 2 videos (30 second and 5 second) and this consumed 49% of my battery.
May I send you any logs or another help with testing?
Anyway many, many thanks to you!
Edit: After recording this kernel is sometimes spontaneously turns on the display including four buttons at bottom, in that moment the LED lights up in orange (wake) and immediately off again and the LED turns green (sleep). Display lights approx. 1 second.
Click to expand...
Click to collapse
This patch does absolutely nothing for recording audio. I would ask how it worked before, but you've probably never been able to test it.
So long as it fixes the cam, we're good. Recording/audio is completely separate from this patch.
arrrghhh said:
I was under the impression that the 'improvements' would actually help all RHOD's. I know when I ran brinka's kernel for testing, the low-light performance did seem better.
So unless it outright breaks all other RHOD's, I'd say it should be applied to all RHOD's.
This patch does absolutely nothing for recording audio. I would ask how it worked before, but you've probably never been able to test it.
Click to expand...
Click to collapse
Sorry, I did not know this. Before the camera really did not work at all. There is tremendous progress. Thanks.
Tested on Rhod100.
milda25 said:
Sorry, I did not know this. Before the camera really did not work at all. There is tremendous progress. Thanks.
Tested on Rhod100.
Click to expand...
Click to collapse
Yes, it is nice to have the cam working at all, and I realize you couldn't test this before.
I just wanted to make that clear, this will only fix the broken cam. Nothing else...
Both RHOD100,210,300 user had crash
Use function get_machine_variant_type to get rhod type, it will return
MACHINE_VARIANT_RHOD_1XX or MACHINE_VARIANT_RHOD_2XX, MACHINE_VARIANT_RHOD_3XX,MACHINE_VARIANT_RHOD_4XX,MACHINE_VARIANT_RHOD_5XX
muziling said:
Both RHOD100,210,300 user had crash
Use function get_machine_variant_type to get rhod type, it will return
MACHINE_VARIANT_RHOD_1XX or MACHINE_VARIANT_RHOD_2XX, MACHINE_VARIANT_RHOD_3XX,MACHINE_VARIANT_RHOD_4XX,MACHINE_VARIANT_RHOD_5XX
Click to expand...
Click to collapse
Exactly !!!
here is some pseudo to brighten everyones day
Code:
current_variant = get_machine_variant_type();
if ((current_variant == MACHINE_VARIANT_RHOD_1XX)) {
do_rhod100_poop();
}
ImTuxy said:
--update2 feb 08 below
Hi,
Sorry to post here, as new user I don't have access to the Android development board.
I have altered [ACL]'s latest kernel (2.6.27-46 git g6a073c7 from 2 feb) to support the Rhodium 100 camera. The update package and the diff are attached.
The change does essentially the same as an earlier change to Andoid SD posted by brinka123, but is implemented differently to prevent upstream rejection as happened to the patch by brinka123. The update package is the 2 feb update that [ACL] posted with the kernel replaced. Can someone can post this to the devel board? I'm looking for testers...
Thanks,
Eric.
--update1 (new user = no new post to devel board):
Thanks arrrghhh for moving my post here. Yes, the zip can be flashed from SD card from the boot menu.
[ACL], the changes apply to all MACH_TYPE_HTCRHODIUM machines (from mach-types.h), that includes all GSM Rhodium devices I believe. I don't know how to narrow that down to the 100 alone, aside from using a kernel boot parameter.
As for the intended scope for this change: most people reporting camera issues are rhod100 users, but I've seen posts from non-rhod100 users having occasional camera crashes. Because the patch targets the used frame rate it is likely that the camera hardware in most rhod100s - and some non-100's? - just can't handle the original framerate. So if there are non-rhod100 users having occasional camera crashes...
--update2
Changed patch to make it rhod100 specific using machine_variant_type. Thanks muziling. See attached zip and diff (postfixed _1). Non-rhod100 users with crashing camera's -if any- should use the original zip to test.
Please note that this patch does not include brinka123's change for low-light conditions. Didn't that one cause problems when zooming in? I can look into that change, but would like to separate it from this patch.
Next thing I want to do is look into the audio issue when using the cam - audio runs for 1 sec, then drops. I need to go into Android code for that*
I've worked hard this evening to compile OMGB with [ACL]'s device specific files (both github), but failed miserably. Looks like I'm missing the rhodium makefiles, any pointers?
I did manage to get 7.5 GB of sources on my PC, so I guess I'm at least halfway
*: while recording video logcat shows a happily recording cam and then suddenly:
V/Libacoustic-wince( 85): msm72xx_start_acoustic_setting
I/AudioHardwareMSM72XX_wince( 85): disabling volume method=AUDIO
V/Libacoustic-wince( 85): msm72xx_set_acoustic_table 256 0
V/Libacoustic-wince( 85): Use current device 13
Click to expand...
Click to collapse
we share acoustic and libaudio with xdandroid. Just compile it there and move the binaries over. Detule is the master of these for now and he has been killing bugs left and right.
Also your second patch looks worthy. So next round of updates i'm going to include it.
We are tracking this issue on the issues list.
http://code.google.com/p/rhodium-nand/issues/detail?id=15
You can update the request if you have more info.
I already saw a lot of kernel developers here, each of them posting their own version.
I don't think that "download sources / fix them / apply patches" by every one of them is ok.
If all could focus on a single source-tree and fix / apply patches to that we would get to a stable/improved version a lot faster.
I can provide a linux machine for the developers interested by this project.
Hardware: 2 x Xeon X7550, 16GB RAM (can be extended to about 60GB), 300GB of storage (can be extended) - RAID6, FC dedicated storage.
Example:
$ time make ARCH=arm clean
[...]
real 0m2.479s
user 0m0.953s
sys 0m1.151s
$ time make -j32 ARCH=arm CROSS_COMPILE=arm-eabi-
[...]
real 1m4.720s
user 19m11.694s
sys 3m23.190s
Click to expand...
Click to collapse
Software:
Slackware 64bit 13.37, gcc 4.5.2, gcc-arm 4.6.1
OS can be changed if you have good enough arguments.
SSH access, no root.
If any developer is interested by an account, pm me with the desired username.
Have fun!
Ok, if no one is interested, I have to start this alone...
BETA
First release - ALiCE Kernel - with patches/tweaks from eternity/franco/bricked kernels and some of my own. Everything seems to work on my HOX.
- Sweep2wake included
- modules built in kernel, no need to flash anything else but boot.img
Attached:
zImage - for including into your own boot.img
boot.img - InsertCoin 5.3.0 boot.img with this kernel.
DELETED ATTACHMENTS - Kernel was virtually unusable.
You can use zImage injector ( http://forum.xda-developers.com/showthread.php?t=1647398 ) to update your own boot.img
I like the idea of this collaboration of kernels.
And I like how the modules are integrated into the kernel.
I'll be testing this out more tomorrow with a battery test for a work day
Keep up the good work
EDIT:
3G Does not work.
As in it shows 3G/H on the top, but no network connectivity.
WiFi does however work.
Great
I'm not a kernel dev, but this seems like a good idea.
Kernel devs working together to create a solid/stable base kernel.
If they want to add specifics they can always release one aside of this.
Also good to integrate modules into boot.img
Keep up the good work.
+1
Good idea, and go on
Good work.
Well I build kernel in 1 minute on i7 920 @4.2 ghz, no need for you machine ;-)
But common git would be nice.. I have zero time to maintain a kernel for HOX
Sent from my HTC One X
It will be nice if we can have a common github repository for the OneX sense kernel with all the patch applies by the devs.
AliceXES, do you have a git link of your repo ?
Because I currently compiling the franco's repo with some config tweek for my own need. And I would like to compiling yours just for testing.
Anyways, thanks for starting your project
Please send me your twitter account it's for helping you
The biggest problems ain't hosting or building times, just version-control. A common Git would be nice, although it seems most changes get picked by eachothers at github.
What about a GitHub organisation? You can have free ones where everyone is admin if you leave the source open. But then that requires a certain level of trust I suppose, heh.
The problem was with modules - for some strange reason, 3G doesn't work with them built-in the kernel.
Also my laptop crashed. The 2nd HP 4520s dead in my hands.
I will probably won't work on this anymore until it's repaired.
Still, if anyone needs access to the compile-server, the offer is still open.
AliceXES said:
The problem was with modules - for some strange reason, 3G doesn't work with them built-in the kernel.
Also my laptop crashed. The 2nd HP 4520s dead in my hands.
I will probably won't work on this anymore until it's repaired.
Still, if anyone needs access to the compile-server, the offer is still open.
Click to expand...
Click to collapse
Sad happenings. Hopefully it'll be fixed soon so you'll be back on track!
1: 3G problem indeed lies in the modules (linked to one of the binary baseband module)
2: getting collaborators won't be easy; many (apart from a select few) of today's "chefs" (dare not call them devs) prefer to act alone, get the credits, instead of working together, where the progress would've been much faster. This has been discussed too many a time on xda.
It is so much easier to rip someone's work & claim it as your own... Which is why many a dev resorted to "protecting" their roms (for example, from dumping).
Another reason why not many would like to join you, is that then it would come apparent that they don't have any real skills, since they won't be contributing any patches. ;]
Why compare ROMs with Kernels though? Maybe I'm unique at this, I don't know but, I never really cared about moving files around at ROM level or building AOSP ROMs. I prefer the kernel-space just a bit more
If people are afraid that their commits get stolen (which unintently happened just a few days ago, it seems) they should sign-off it properly.
Ányway I'm always interested in collaborating. Atm I'm just foring Franco's kernel and fixing a few compiling warnings.. I think what we really need is one main-maintainer which holds the master-branch, then the rest of our bunch just can push commits to him for reviewing. Who this lad is going to be, is also a tricky one.
I don't think I will have any success with this project
I started my own kernel thread (here: http://forum.xda-developers.com/showthread.php?t=1662781 ), sorry.
Anyway, the invitation is still open.
wooo HQ playback on youtube
Ganster41 said:
Hi, low-end devices users! I have good news for you
As you know, Qualcomm has ended support for their SoCs, based on ARMv6 core, and doesn't release OpenMax IL libraries for Android 4.0+. Someone was crying on Qualcomm's forum, someone try to understand, how to extend GB proprietaries to support new Google OMX extensions, but nobody try to modify libstagefright, and disable using new unimplemended functions...
I spent about a few weeks, learning stagefright architecture, and differents between GB and ICS OMX layers...and now I ready to show it to you
I have only ZTE Blade, and can make ROM only for it. You can download it here. In addition to worked hardware-accelerated video playback, and camcorder, it builded with Linaro GCC 4.7.1, and has a little UI speedup(if it not a placebo ). ROM based on KonstaT device tree, thanks him for it.
Oh, my Dropbox temporary blocked to public links. I upload ROM to letitbit too.
Modified framework's sources can be found on my github. Besides it, you need to add one global define to your device's BoardConfig.mk - COMMON_GLOBAL_CFLAGS += -DQCOM_LEGACY_OMX
UPD: I make same changes in CM10 sources tree, but it doesn't working, and I can't try to fix it, because haven't enough disk space to build CM10 ROM. I think, Google changes OMX API again, and it needs more fixes to get it working. You can download sources from here. For now I not interestid in CM10, because now it laggy and has some not good issues.
UPD2: Please, if you want my help with integration problem, attach logcat at the time, when you try to use vide playback/camcorder. I can't help without any information.
UPD3: If you trying to make port for your device, this post can be helpful. Thanks to cougarcougar for it.
UPD4: We still get errors, if trying to play videos from some apps(e.g. Android browser) in not-fullscreen mode. gralloc or mmap returns error, when try to map buffers from NativeWindow. If anybody have ideas how to fix it, please write it here, or to my PM...
Important addition!
Devices based on MSM7x27 chips has two different versions of OMX libs.
"Oldt"(for froyo?) has an unknown padding between color components parts of returning buffer. I have fixed that for most videos, but some strange resolutions are still gets broken colors with green line on top.
"New" version are present in Samsung/LG devices, who has official Gingerbread ROMs. It returns correct buffer in dfferent color format(YV12, instead of NV21), but it laggy on VGA+ videos. Now don't know why. May be it convert resulting buffer to YV12 on CPU... I will try to understand it later.
I think you can use "old" libs from ZTE Blade on any device, because "new" libs work on ZTE Blade too.
PS: If you want to thanks/support my work - you know where you can find button for it.
Click to expand...
Click to collapse
Yes it's Possible but our 3D Still isn't functioning ! So For now It will not work !
hmmm, that is an interesting problem lol,,
Hi!
I have great respect for the people that give us our great ROMs, and i KNOW that that is hard - but my question is: why exactly is it that hard?
This is just a question out of curiosity, because I would really like to understand the unerlying problems that cause all the other issues.
I was under the impression that the Android stack runs on top of the Linux kernel.
Usually, the Linux kernel is the Hardware Abstraction Layer, and apps and ROM, in theory, should be kind of hardware agnostic?
e.g. the Bluetooth Issue on our Captivate Glides: I would guess that Android communicates, through some API, with the kernel's BT stack/driver. There must be some (open or closed source) driver available (worst case: some .so module ripped out of an official ROM, maybe?). So why does the headset profile not work? Did the APIs change? Are custom ROMs forced to use another version of the driver?
It also happens to this 50$ chinese tablet i have here: some ROM screw up the touchscreen, some break audio, and so forth. Why can't there be some way of installing a generic ROM, and then side-loading the OEM's drivers?
Thank you again to all ROM developers! This is NO WAY a complaint. Just pure curiosity!
I may be out of my league when trying to describe this, but the processor in our phones is somewhat different to the processor in the bulk of other phones. This is where majority of the issues came from in porting ICS to the glide before ATT released it. Even after the first official ICS update, the modders here were the ones who fixed the keyboard lights... I changed up to JB because the GPS wasn't locking quick enough and PACROM had all the quick toggles and the speed/gps lock I needed.
Sure the kernel is the underlying part that pulls it all together, even still there is all the drivers that need to work with it. If there isn't a bluetooth/wifi/HW Video driver for the version of the kernel, then it gets really tricky and now its coding for a piece of software to speak with the hardware ..... We have things that partially work, but not fully ...as with everything computers, in theory things that "should" work, don't always... I'm an IT tech.. I run into weird **** all the time that "should" work ... takes time, but with persistence and the right skillset, majority of the time a resolution can always be found.