Related
Hey guys,
Torch Mobile has another version of the Iris browser released. It loads pages up faster and feels more like a stable browser now.
I found that it renders pages while scrolling -alot- faster then the opera browser on Duttys 2.3 rom, has an incredibly proper scrolling feel, and a very... minimalistic UI. (basic windows mobile buttons, nothing special there.)
At this stage I would even say that the Iris browser beats Opera in rendering, the other departments are still lacking though (think features and UI.)
Get it at www.torchmobile.com
Fully supports WVGA.
I tried this browser (ver 1.1.4): fast and stable but no Flash Support.
Now ver 1.1.5 haven't Flash Support too...
D'rath
couldn't get flash working either, where the old versions did work. Not sure if thats down to the ROM I was using at the time though. However I thought this browser supported flash out of the box?
I have the same problem as well. Does anyone know if there is a fix for this?
true - Iris is realy fast. no lag when scroling
Iris is faster than opera so I fully recommend Iris browser
Thanks for the info, I'm going to have to check this out!
Can someone up this freeware here to download? pls and thx^^
The adaption of the newly released VegaComb / honeycomb 3.0 for our tegra2 brothers (advent vega and Adam) and is getting to a state where its usable and the latest alpha4 release for Vega is working quite well on Folio100 as well. with a few modifications of course...
I cannot take full credits for the intensive work done on this honeycomb 3.0 , that is primarily done by NotionInk Adam and Advent Vega developers , which are: MrGuy , newbe5 , corvus , HomerSp I added some kernel changes and image adjustments to support A7.
Download A7Comb 0.2a patch update here
installs like any other "Update.zip", rename the downloaded file to Update.zip
Download A7Comb 0.2 full image update here
installs like any other "Update.zip" (extract the Update.zip from this downloaded zip file) and make sure you "wipe" / factory reset.
Alternate kernel, with original softkeys enabled can be downloaded here
this is also used when you change density setting to 130, so you get the "gingerbread" launcher running instead.
Rename this download to Update.zip and copy directly to sdcard. no unpacking for this is required.
So what is status on a7 port.
- Wifi works, you need to reboot the first you enable it, and it will scan correctly.
- touchscreen seems 100% ok. (did not test multitouch apps)
- Adobe Flashplayer blank (just keep pressing upper left corner like normal to get fullscreen and it works)
- too many apps in the apps list makes them go outside screen.. one solution might be to change density. see build.prop and maybe try 110 instead of the current 120.
You can write whatever status or reported finding, but please check, its not already in the advent/vega issue list, as it share alot with their image.
I will do what is possible to bring it to a better state, but i cannot promise anything and maybe patches from vega/adam might actually work on A7 depending on what they change. (if its a patch)
v0.2a
- Increased 2d/3d performance
- polaris office fixes
- brightness control fix
v0.2 updates
- using newest updates from VegaComb (Gmail and other googleapps now shows correctly)
- Market can now be used for login with an Googleaccount.
reserved for me
I did get bigrushdog to take a look into making us a kernel he is the one who has been working on them for the xoom.
And its online.
Thanks for HC dexter I am testing it now...
Been playing with it for a few hours. touch on the screen is hit or miss at best. Market is a non-starter. Titanium Backup is crashing every other app install. Unable to load Amazon App Store anymore (just stuck in a non-ending registering cycle) But on a good note looks great in landscape, Portrait not so much. Wifi started right up after restart and found my network just fine. Will play a little bit more.
Google Apps working now!!
Ill post the new image later on.. and "Books" now stays (was automatically removed before)
Had to revert back to 1.42, no soft key work. Will wait for new update..
Sent from my A7-040 using Tapatalk
tumpy said:
Had to revert back to 1.42, no soft key work. Will wait for new update..
Click to expand...
Click to collapse
softkeys disabled.. Honeycomb do not use them anymore
Look at the bottom left, thats your control buttons.. thats pretty much what as example "motorola xoom with honeycomb 3.0" looks like now.. so its no error , i disabled those on purpose..
problem is that you got half the screen size of a "certified" tablet, so not much room for pressing buttons and resolutions very low.. so you're missing alot due to the lack of space.. and thats pretty much why A7 is never getting a proper honeycomb when minimum requirements are 1280x800
Soft keys were removed If I had read correctly due to the fact HC has them and dex seen no reason to have two of them. I like the idea of not having them means you don't have to worry about hitting them on accident
http://www.slatedroid.com/topic/179...otloader-froyogingerhc-works-for-notion-roms/
adams kernel was this the basis a source you used to make changes to ours?
rombold said:
http://www.slatedroid.com/topic/179...otloader-froyogingerhc-works-for-notion-roms/
adams kernel was this the basis a source you used to make changes to ours?
Click to expand...
Click to collapse
no, i used StreamTVNetwork's released source from their website..
you cannot use other devices unless you once again try to adapt the drivers to the kernel, which is a big one, since no one did, you can imagine how much work it takes..
you modifiy the existing kernel you got for your device, which the git changes where possible into your existing code, and update where it requiress it.
So we could maybe get the 1.5Ghz update, but im not sure if i can extract and diff it so we can implement into the a7 kernel.
I wasn't meaning did you use that kernel. I guess I could have been a bit clearer. What I meant was seeing how that kernel is adapted to be used with HC could that be off benefit to a dev for our a7. Using it as a guide to some degree
This may be a silly question but...with a dedicated gpu could not the ROM resolution actually be resized to fit the A7? I mean this is not a case of trying to increase resolution (at its native resolution you can't get more than it can reproduce) but down converting it. In other words (This may be a bad example) a standard 720p television that can receive a 1080p signal but down-converts it to 720p.
amwilliams9 said:
This may be a silly question but...with a dedicated gpu could not the ROM resolution actually be resized to fit the A7? I mean this is not a case of trying to increase resolution (at its native resolution .
Click to expand...
Click to collapse
with the next update, im uploading in some hours you can use Market, then download the "Density" app, which can change density (not resoluion) but everything becomes smaller and its harder to hit the soft buttons in lower left side, so you know (as i tried it)
Hi Dexter: Thanks for your work. I m new w A7 and try yet this update but bluetooth not turn on...
wait for you new release. Thanks again.
v0.2 is online
V0.2 is online. Got Googleapps login fixed, so you can use Market and Gmail (Using apps from latest VegaComb)
ming_a said:
Hi Dexter: Thanks for your work. I m new w A7 and try yet this update but bluetooth not turn on...
wait for you new release. thanks again.
Click to expand...
Click to collapse
i can almost say 100% Bluetooth will never work on this rom!
so don't wait for it, then you can start looking for a new tablet with 3.0
Notice the 02 image is much smaller than previous image, about to test this one..I think GB will be out best bet for the A7, I am satisfied with froyo, if HG is out of our reach how about Gingerbread..is it possible Dexter?..
Sent from my A7-040 using Tapatalk
tumpy said:
Notice the 02 image is much smaller than previous image, about to test this one..I think GB will be out best bet for the A7, I am satisfied with froyo, if HG is out of our reach how about Gingerbread..is it possible Dexter?..
Sent from my A7-040 using Tapatalk
Click to expand...
Click to collapse
no, basically a7 is stuck on in 2.2. a 2.3 release still require a formal 2.6.36. kernel which vendors do not adapt drivers for, so if any 2.3 arrive, it will be like this one, using a 2.6.32.9 kernel. maybe with a few patches upto 2.6.32.34 or so, but still using the old drivers vendors delivered..
the guys found out several "libs" of 40MB+ were not needed at all, so i removed them as well..
Weird, Upon first install i recived " Installation aborted" Due to some E:Can't find entry for META-INF/com/google/android/update-binary. Any ideas? Trying install again from fresh download.
Update: No go 2nd time around..... ?
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
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,,
Since modifying OMX cores, ibstagefright, and the qdsp service were unsuccessful in enabling full hardware acceleration in videos, and camcorder...
How about if their leader (the adreno 200 drivers) is the culprit of all the sluggish hardware acceleration! on the ARMv6 phones like ours.
Going to the point, has anyone made a pursuit in modifying the drivers itself? like forcing the drivers to be compatible with the modified libstagefright and also OMX cores? coz it seems they function as a whole, i mean, there is some sort of unity going on when they're in operaiton. (just an opinion)
Since Qualcomm released these drivers, how about the connections going to the OMX cores, ligstagefright, or even the qdsp service? Did they modified it? or just remained the same, like the drivers in GB?
Coz I gotta feelin' that the drivers is the bug here...
From what I have read in this post "Fixing the OMX Driver problem in ICS"
scottrix said:
OK, I have put lots of tracing for all omx calls to the binary codec in the omxcore and got logs for this from both ICS and GB. There isn't any difference in the calls and there aren't any differences in the parameters passed to those calls. Looking at include files the structures used in these calls have not changed (which might make the tracing look OK, but the binary data different there by upsetting the GB driver when given ICS structures). My only conclusion is that the ICS drivers for hardware graphics acceleration (EGL, GLES, OpenVG) use more resources from the qdsp5, or affects the qdsp5 in a way that stops the GB OMX codecs working. I believe the ICS graphics drivers from QCom are:
vendor/qcom/msm7x27/proprietary/lib/libsc-a2xx.so
vendor/qcom/msm7x27/proprietary/lib/libgsl.so
vendor/qcom/msm7x27/proprietary/lib/libC2D2.so
vendor/qcom/msm7x27/proprietary/lib/egl/libGLES_android.so
vendor/qcom/msm7x27/proprietary/lib/egl/libq3dtools_adreno200.so
vendor/qcom/msm7x27/proprietary/lib/egl/libEGL_adreno200.so
vendor/qcom/msm7x27/proprietary/lib/egl/eglsubAndroid.so
vendor/qcom/msm7x27/proprietary/lib/egl/libGLESv1_CM_adreno200.so
vendor/qcom/msm7x27/proprietary/lib/egl/libGLESv2_adreno200.so
vendor/qcom/msm7x27/proprietary/lib/libOpenVG.so
vendor/qcom/msm7x27/proprietary/etc/firmware/a300_pfp.fw
vendor/qcom/msm7x27/proprietary/etc/firmware/leia_pm4_470.fw
vendor/qcom/msm7x27/proprietary/etc/firmware/leia_pfp_470.fw
vendor/qcom/msm7x27/proprietary/etc/firmware/yamato_pfp.fw
vendor/qcom/msm7x27/proprietary/etc/firmware/a225_pfp.fw
vendor/qcom/msm7x27/proprietary/etc/firmware/yamato_pm4.fw
vendor/qcom/msm7x27/proprietary/etc/firmware/a225_pm4.fw
vendor/qcom/msm7x27/proprietary/etc/firmware/a225p5_pm4.fw
vendor/qcom/msm7x27/proprietary/etc/firmware/a300_pm4.fw
Of these files I could only find the following in GB:
system/lib/libgsl.so
system/lib/egl/libGLES_android.so
system/lib/egl/libEGL_adreno200.so
system/lib/egl/libGLESv1_CM_adreno200.so
system/lib/egl/libGLESv2_adreno200.so
So I deleted the missing ones and copied the GB ones over the ICS ones. This seemed to give me a "working" system, but with no display. Does anyone know how to get graphics on ICS working without using hardware graphics drivers ? If I could do that it would test my theory that the ICS hardware graphics acceleration libraries (EGL, GLES and VG) are stopping the hardware OMX codecs from working.
Click to expand...
Click to collapse
maybe from here there should be some very useful info in getting along the OMX cores and codecs, and the adreno drivers
Hopin' this could really help in improving ICS in our devices.
Can I ask one possibly silly question...? Video acceleration is flawles on jellybean, right? How can it be fully functional in JB and not in ICS...? I mean... Was any kind of driver released on JB and not on ICS...?
polfrank said:
Can I ask one possibly silly question...? Video acceleration is flawles on jellybean, right? How can it be fully functional in JB and not in ICS...? I mean... Was any kind of driver released on JB and not on ICS...?
Click to expand...
Click to collapse
After JB was released, there was no point to continue work on ICS. So our devs continued their work on JB and found a way to get it work.
4ndaKava said:
After JB was released, there was no point to continue work on ICS. So our devs continued their work on JB and found a way to get it work.
Click to expand...
Click to collapse
ooh. okay, that's odd. hardware video acceleration works on JB, while the adreno drivers are based on ICS? Afaik, the ICS drivers were used in JB and it worked, but when it comes to the OMX, like we already knew, HW acceleration works after some modding on the core libraries (right?)
If the ICS drivers are not used in JB, the devs might knew something about this (Driver - OMX).
man! I think it's time to reverse engineering the OMX cores, together with the QDSP service (I think, its his master) then )