Jump to content

skywave

Members
  • Content Count

    138
  • Joined

  • Last visited

Community Reputation

56 Excellent

About skywave

  • Rank
    Regular
  1. Actually AOSP Gingerbread is not really compatible with ARMv6 either. CodeAurora made mutiple changes to get the browser working with the V8 javascript engine
  2. Regarding OpenMAX i made a lengthy post http://www.modaco.co...e/#entry1952640 in short, we already have openmax drivers as there was openmax in Gingerbread. But there are incompatible with ICS. To ever get the QDSP5 OpenMAX driver working on ICS/armv6 need Qualcomm to give a compiled version on ARMv6. They did release the source for the other HW decoding (userspace) drivers, so there is very likely a problem with intellectual property releasing the source code. Its very well possible this also applies to compiled binaries :|. And for that Sony device, it really is the MSM7227A.
  3. There will not be a MSM7227 ICS update ever on any device. There is no CAF release for it, nor work to get to that phase. Nor is there demand, they want to push the GPIO pin compatible MSM7227A which is a snapdragon.
  4. Sigh.. The Sony has a MSM7227A too. You guys all hang up to one article where its a obvious typo. Google has more hits to Sony ST21i MSM7227A than to Sony ST21i MSM7227.
  5. There is a very very tiny chance though, that there is an updated QDSP5 Openmax wrapper somewhere in some gingerbread rom. But then again its more likely that qualcomm kept these changes in an ICS branch.
  6. Yeah but stare_spb is right. OMXnoddeInstance (part of libstagefright tries to access those two methods, get unimplemented back so it moves on to the next codec. Which is the software codec. The obvious hack is indeed to try to get revert back omxnodeinstance to try to workaround these two methods, by for example revert those two commits i put in the big post. But there could be tremendous sideeffects of that, they were commited in Feb 2011. Quite resonable to assume they are used all over in ICS and upcoming NDK apps.
  7. The OPENMAX IL specification is online btw. getExtensionIndex is on page 79
  8. No it isn't. Its the MSM7227A, the same SoC as the ZTE the rom in the OP is from. http://www.themobileindian.com/news/6323_Entry-level-Sony-Tapioca-smartphone-spotted-online http://pdadb.net/index.php?m=specs&id=3528&view=1&c=sony_xperia_st21__st21i_sony_tapioca
  9. Well to be honest they did release the source of the OpenMAX wrapper for the QDSP6 and VIDC API's and codeaurora is excellent if you exclude a few things. Dunno if there other SoC companies that offer a codebase like CodeAurora does.
  10. Thank you, much appreciated. It's interesting as every prop lib needed to get HW video decoding on the Blade is there, which is a userland QDSP5 driver to interface with libstagefrighthw . Just in ARMv7 :|. There seem to be not that much differences between QDSP5 and QDSP5v2 as i thought (there are seperate drivers in kernel though). Just need some Qualcom engineer to compile vendor/qcom/proprietary/mm-video/qdsp5 in ARMv6. To put an end to all the nonsense written over this HW video decoding, which reached a new low with that pathetic attempt this week. Hardware video decoding is done by the SoC. There are various steps in handling this. First there are the drivers in the kernel space, which does the memory allocation etcetera. https://github.com/b.../mach-msm/qdsp5 Then in the userspace there are these proprietary libraries, which are a blackbox to me. But they talk to the kernel space via the various files (Unix talks to all devices via the fily system) in the QDSP5 API language. Then they function as the OpenMAX API for the Android OS and there is libstagefright (working of this OpenMAX api) which functions as the Android API for apps like Youtube. AFAIK in Gingerbread there is already this OpenMAX api, but in ICS NDK they opened it up for native apps to communicate directly to the OpenMAX API to avoid latency for apps. So then you're probably wondering why is my badword YoutubeHQ not working then? Well they changed libstagefright, i guess they are using a newer OpenMAX API version. This is what happens if you try HW video decoding on ICS. As you can see it loads the qcom decoder but then the qcom decoder craps out because of two not implemented commands: get_config and get_extension_index. You can pinpoint these changed to this commit to the android base frameworks/libstagefright. https://github.com/a...00279963965a677 and this commit https://github.com/a...ea798762916ff5c Basically that is why it broke down and this needs to be implemented in the libraries that interface QDSP5 to OpenMAX. This is easy if you have the code. The code is available for QDSP6 and other Qualcomm API's like this. But not for QDSP5 which most likely is cause there is code is legally not allowed to be licensed with a opensource license such as GPL. I don't hope the same problem with intellectual property doesn't exist for compiled libraries that would prohibit Qualcomm to publish compiled ARMv6 libraries as they did for the Adreno drivers. The dev community obtained these libraries before by getting them from existing roms. This will NOT happen and i repeat there will not be any ICS update to ANY armv6 phone of Qualcomm. For example ZTE doesn't base their ROM's on AOSP, they use CodeAurora which releases a full package which is fully compatible with the SoC they buy including all drivers and kernel. This ZTE N880E rom is clearly based from a CAF version. But there isn't an CodeAurora release for the MSM7x27 and the CAF ICS codebase is as incompatible with v6 as AOSP. In Gingerbread they made all kinds of commits to make Gingerbread compatible with v6, such as Webkit and V8. In ICS-CAF there hasn't been single one. Timezones are still f*cked, Webkit uses JavaScriptCore which is a lousy and barely functional javascript engine (as compared to V8). And there isn't much incentive for Qualcomm/CodeAurora to want to support ARMv6 MSM7227, in fact it is the opposite. Last year they released a pin-compatible snapdragon which is put in the market as a cheap solution to extend the lifehood from platforms such as the Blade. This enables ZTE to just take the platform which is completely designed already and replace the MSM7227 by the MSM7227A without much changes to the kernel as GPIO pins are still the same.
  11. Actually not so much. The CDMA stuff has nothing to do with kernel. The screen could be a though one as ZTE did really crap job implementing their screen drivers, including hacking up msm_fb.c But then again its likely they did the same butch job for this driver. And kernel wise that new CPU isn't a dealbreaker either, you can diff board-msm7x27.c with board-msm7x27a.c and then see the differences. Biggest problem will be the WiFi driver. Problem is, is this a true 3.0.8 or just a 2.5 with s*** backported and the version number changed. We've seen this before... Although this might be interesting to use in current ICS roms: ro.build.fingerprint=ZTE/N880E_ICS/atlas40:4.0.3/IML74K/eng.zhangchun.20120426.194244:user/release-keys Then at least your device aint a GNexus but a ZTE. BTW Could somone mirror the entire rom please? 10KB/sec are not speeds i've been used to in the past 13 years ;)
  12. OpenMAX is working like it was before, using the software decoders.So no Youtube HQ.
  13. It's very safe to say hardware video decoding will never work on any MSM7227 based device (i dont see the snapdragon MSM7227A as msm7227 based).
  14. Yep and the Raspberry-Pi has a broadcom SoC btw. Something else is noteworth from the Raspberry-PI, the thing only supports a few of the possible HW decodeable formats by the SoC. Reason? Money, you have to pay a license fee per format supported. The MSM7227 is special because its the only non-spadragon with Adreno200 making it ICS compatible. Theres even a possiblity this thing isnt even capable of running openmax. And for the releasing part, it isnt available for the HTC sensation too, so chances are very very slim to ever see ICS running like it should.
  15. HTC Explorer has a MSM7227A which is a snapdragon with Adreno 200 clocked at 800+ Mhz.
×
×
  • Create New...

Important Information

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