Develop Bugs

Screen delay issue (kernel issue found)

Basically, as we all know there is a delay when turning on the screen. I have been looking through various kernel files and trying to find the source of the problem. and I believe that I have found part of the problem!
The first errors that I found happened each time the screen was turned on, in the log it showed....
[ERROR] msm_i2c msm_i2c.0: error, status 63c8 (5C)
[ERROR] msm_i2c msm_i2c.0: Error during data xfer (-5) (5C)
[ERROR] msm_i2c msm_i2c.0: error, status e3c8 (34)
[ERROR] msm_i2c msm_i2c.0: Error during data xfer (-5) (34)
This lead me to believe that it was an issue with the msm files in the kernel...
I then found two of the errors in a file I found on the HD2 Kernel GitHub... the link to the file is also below....
https://github.com/charansingh/cm-kernel/blob/master/drivers/i2c/busses/i2c-msm.c
Code:
if (ret < 0) {
dev_err(dev->dev, "Error during data xfer (%d) @%02X\n", ret, msgs->addr);
msm_i2c_recover_bus_busy(dev);
}
Now I have started C robotics programming quite recently so I was hoping that it would help me here! This loop obviously checks if the variable ret is < 0 and if it is it will display an error message! Now earlier in the code ret was set using
ret = msm_i2c_poll_notbusy(dev, 1);
This led me onto the function
msm_i2c_poll_notbusy....
Code:
msm_i2c_poll_notbusy(struct msm_i2c_dev *dev, int warn)
{
uint32_t retries = 0;
while (retries != 200) {
uint32_t status = readl(dev->base + I2C_STATUS);
if (!(status & I2C_STATUS_BUS_ACTIVE)) {
if (retries && warn)
dev_warn(dev->dev,
"Warning bus was busy (%d)\n", retries);
return 0;
}
if (retries++ > 100)
usleep_range(100, 200);
}
dev_err(dev->dev, "Error waiting for notbusy (%d)\n", warn);
return -ETIMEDOUT;
}
As far as I can see, with no kernel programming history in my life, it sets the unsigned integer retries to 0, then starts a while loop testing
readl(dev->base + I2C_STATUS)& I2C_STATUS_BUS_ACTIVE
If the result of this is false it will return that the bus was busy for so many tries, it then exits out of the while loop returning control to the rest of the function...
otherwise ( in our case ) it will increase the variable retries by one and if there have been more than 100 retries it will have a 10 millisecond delay before returning control back to the top of the while loop. After 200 retries the while loop is no longer valid and then it will exit...
The cause for the around 2 second delay is partially due to the phone waiting until this loop has finished before it has turned the screen fully on! the 100 tries of the 10 millisecond delay equates for 1 second of the delay, so if we could fix the loop problem this WILL increase the speed at which the screen turns on... the other error is caused by
Code:
if (status & I2C_STATUS_ERROR_MASK)
goto out_err;
out_err:
dev_err(dev->dev, "error, status %x (%02X)\n", status, dev->msg->addr);
dev->ret = -EIO;
I do not believe that this error is causing a slowdown but they are related.
The problem always involves the variable status so this probably gives a good idea that whatever sets status must be incorrect...
Anyhow I have never touched kernel scripting in my life, I am 15, so I may be completely wrong, but from what I can see I hope that I am at least partially right!

Wow! Good stuff!

Wow nice find, perhaps you should talk to Tytung & Rafpigna about this as they are the most active kernel chefs @ HD2

patensas said:
Wow nice find, perhaps you should talk to Tytung & Rafpigna about this as they are the most active kernel chefs @ HD2
Click to expand...
Click to collapse
Thanks, I have now contacted them and am awaiting a reply

Kernel source code related to msm_i2c is done by the great dev Cotulla. (and maybe other devs)
I don't participate in his work.
And you're linking to a non-working kernel git in your first post.

but tytung please try to look into this ?
because this issue is really annoying and I dont think cotulla would mind if you do some modifications to his great work ?

Nice! now the only thing left to do is to fix it =))

Farrrk now what....??
-Wrong thread... sorry.

Well, I'm waiting for screen delay issue to be fixed since I installed MAGLDR on my HD2. So it will be just great.
What if just remove this loop and sleeps and recompile kernel? Madness? THIS! IS! SPARTA!

Great found kid!! We have great hope on this!
Hope it gets fixed soon...

I didn't understand anything you just said but .... This is great! And your only 15? That's amazing.
Hope we can fix this problem.
Sent from my HTC HD2 using XDA Premium App

nice work. especially if you are 15.
i would be so happy without the wakeup lag.. >.<

Hah ! That reminds me of an old trick to enable hackintoshes to use USB2...
The PC bios never gave back the bus ownership. So correctly programmed software could not use it.
The fix was to take bus ownership without asking "please".
Here it might be the same idea: just ignore (or need to call msm_i2c_recover_bus_busy earlier)
Once back home, if my kids give me spare time, I'll try to setup a compilation environment and give it a try.

john_duff said:
Hah ! That reminds me of an old trick to enable hackintoshes to use USB2...
The PC bios never gave back the bus ownership. So correctly programmed software could not use it.
The fix was to take bus ownership without asking "please".
Here it might be the same idea: just ignore (or need to call msm_i2c_recover_bus_busy earlier)
Once back home, if my kids give me spare time, I'll try to setup a compilation environment and give it a try.
Click to expand...
Click to collapse
Good idea, im sure that calling it earler and avoiding the loop will reduce the delay, after that is done we need to find a 'clean' hack as calling msm_i2c_recover_bus_busy would probably still add a delay, albeit not as much as if we just left it Good luck in your testing...

You guys speak like you've found the solution lol =D

Well not tonight... bad news came, I have to fix the dishwasher first.
I'll keep you informed.

john_duff said:
Well not tonight... bad news came, I have to fix the dishwasher first.
I'll keep you informed.
Click to expand...
Click to collapse
Hey can the dishwasher remove the screen delay? NO!
only joking ! Im just so excited for this !

white-energy said:
You guys speak like you've found the solution lol =D
Click to expand...
Click to collapse
ahah finding a problem isnt that hard but finding the solution is harder we will probably need some help from experienced kernel coders to help fix it properly

speedyracer5 said:
ahah finding a problem isnt that hard but finding the solution is harder we will probably need some help from experienced kernel coders to help fix it properly
Click to expand...
Click to collapse
Why are you using charansingh's HD2 Kernel GitHub to see the code? Just guessing, it may have .37 kernel code on which work is still going on as its still buggy...
Is there a similar error tytung or Rafpigna or ACA's kernel's git also?

speedyracer5 said:
[ERROR] msm_i2c msm_i2c.0: error, status 63c8 (5C)
[ERROR] msm_i2c msm_i2c.0: Error during data xfer (-5) (5C)
[ERROR] msm_i2c msm_i2c.0: error, status e3c8 (34)
[ERROR] msm_i2c msm_i2c.0: Error during data xfer (-5) (34)
Click to expand...
Click to collapse
Well, I can't argue with that.... I can't understand it either ..
Sounds like you did A tremendous piece of detective work. Nice one.

[KERNEL] Open Community Kernel, OCK + tutorials

Everyone is allowed to make changes to this kernel.
GITHUB COMING
Things to discuss?
- How will we setup the Github? Should we have all users send their id_rsa.pub key and then have the github admin upload it for validation?
- Assigning roles: Who will build the kernel and package it for distribution?

Reserved changelog

Tutorials
Fix screen off clocks & governor reset
1. Download latest Jelly Bean Source Code
2. Browse to device/samsung/tuna/power
3. Edit power_tuna.c
4. Remove these functions completely:
static void tuna_power_init(struct power_module *module)
Click to expand...
Click to collapse
static void tuna_power_set_interactive(struct power_module *module, int on)
Click to expand...
Click to collapse
5. Now remove the text marked in red
struct tuna_power_module HAL_MODULE_INFO_SYM = {
base: {
common: {
tag: HARDWARE_MODULE_TAG,
module_api_version: POWER_MODULE_API_VERSION_0_2,
hal_api_version: HARDWARE_HAL_API_VERSION,
id: POWER_HARDWARE_MODULE_ID,
name: "Tuna Power HAL",
author: "The Android Open Source Project",
methods: &power_module_methods,
},
init: tuna_power_init,
setInteractive: tuna_power_set_interactive,
powerHint: tuna_power_hint,
},
lock: PTHREAD_MUTEX_INITIALIZER,
boostpulse_fd: -1,
boostpulse_warned: 0,
};
Click to expand...
Click to collapse
6. Now compile the AOSP ROM
7. Take the power.tuna.so file from /system/lib/hw/power.tuna.so and include it in with kernel or ROM

reserved even more

great idea

djjonastybe said:
Tutorials
Fix screen off clocks & governor reset
1. Download latest Jelly Bean Source Code
2. Browse to device/samsung/tuna/power
3. Edit power_tuna.c
4. Remove these functions completely:
5. Now remove the text marked in red
6. Now compile the AOSP ROM
7. Take the power.tuna.so file from /system/lib/hw/power.tuna.so and include it in with kernel or ROM
Click to expand...
Click to collapse
Why removing those functions? Just make them return 0 instead of deleting them, its safer.

good things gonna to be here
Sent from my Galaxy Nexus

franciscofranco said:
Why removing those functions? Just make them return 0 instead of deleting them, its safer.
Click to expand...
Click to collapse
But they don't have return values. That would result in a compile error. You can't use void with return
I found no other method by AOKP that reads the max scaling frequency from the sysfs interface. And then restores it. But I think they should have taken cpuinfo.max_freq instead

djjonastybe said:
But they don't have return values. That would result in a compile error. You can't use void with return
I found no other method by AOKP that reads the max scaling frequency from the sysfs interface. And then restores it. But I think they should have taken cpuinfo.max_freq instead
Click to expand...
Click to collapse
I know I can't use return with void, I overlooked they were void functions. Just remove their code or create some dummy coding, I had problems when removing them entirely along with removing: init: tuna_power_init and setInteractive: tuna_power_set_interactive.

Is there room for total novices?

Fixing the OMX driver problem on ICS

I have signed the petition to get Qualcom to release ICS drivers for the marvel device, however, it looks as if they will not be releasing them. So we need to come up with another plan. This thread is to try and start a technical discussion as to how we are going to do this.
Using the information in these posts:
http://www.modaco.com/topic/354020-zte-n880e-first-zte-ics-update/page__st__20
http://forum.xda-developers.com/archive/index.php/t-1588599-p-2.html
http://newsandeducationblog.blogspot.com/2012/05/android-developers-video-videoview.html
http://forum.xda-developers.com/archive/index.php/t-1664335.html
These posts suggest that we are missing some features in get_config and get_extension_index.
For get_config the debug output:
W/QCvdec ( 2751): get_config: unknown param 117440527
117440527 is 0x700000F, which from frameworks/base/include/media/stagefright/openmax/OMX_Index.h
/* Image & Video common Configurations */
OMX_IndexCommonStartUnused = 0x07000000,
OMX_IndexParamCommonDeblocking, /**< reference: OMX_PARAM_DEBLOCKINGTYPE */
OMX_IndexParamCommonSensorMode, /**< reference: OMX_PARAM_SENSORMODETYPE */
OMX_IndexParamCommonInterleave, /**< reference: OMX_PARAM_INTERLEAVETYPE */
OMX_IndexConfigCommonColorFormatConversion, /**< reference: OMX_CONFIG_COLORCONVERSIONTYPE */
OMX_IndexConfigCommonScale, /**< reference: OMX_CONFIG_SCALEFACTORTYPE */
OMX_IndexConfigCommonImageFilter, /**< reference: OMX_CONFIG_IMAGEFILTERTYPE */
OMX_IndexConfigCommonColorEnhancement, /**< reference: OMX_CONFIG_COLORENHANCEMENTTYPE */
OMX_IndexConfigCommonColorKey, /**< reference: OMX_CONFIG_COLORKEYTYPE */
OMX_IndexConfigCommonColorBlend, /**< reference: OMX_CONFIG_COLORBLENDTYPE */
OMX_IndexConfigCommonFrameStabilisation,/**< reference: OMX_CONFIG_FRAMESTABTYPE */
OMX_IndexConfigCommonRotate, /**< reference: OMX_CONFIG_ROTATIONTYPE */
OMX_IndexConfigCommonMirror, /**< reference: OMX_CONFIG_MIRRORTYPE */
OMX_IndexConfigCommonOutputPosition, /**< reference: OMX_CONFIG_POINTTYPE */
OMX_IndexConfigCommonInputCrop, /**< reference: OMX_CONFIG_RECTTYPE */
OMX_IndexConfigCommonOutputCrop, /**< reference: OMX_CONFIG_RECTTYPE */
OMX_IndexConfigCommonDigitalZoom, /**< reference: OMX_CONFIG_SCALEFACTORTYPE */
Is OMX_IndexConfigCommonOutputCrop, so the hardware mpeg4 decoder doesn't understand this index. Going from the source code that calls this, if the call fails then it does something else and carries on
./frameworks/base/media/libstagefright/ACodec.cpp:
if (mOMX->getConfig(mNode, OMX_IndexConfigCommonOutputCrop,&rect, sizeof(rect)) != OK) {
rect.nLeft = 0;
rect.nTop = 0;
rect.nWidth = videoDef->nFrameWidth;
rect.nHeight = videoDef->nFrameHeight;
}
CHECK_GE(rect.nLeft, 0);
CHECK_GE(rect.nTop, 0);
CHECK_GE(rect.nWidth, 0u);
CHECK_GE(rect.nHeight, 0u);
CHECK_LE(rect.nLeft + rect.nWidth - 1, videoDef->nFrameWidth);
CHECK_LE(rect.nTop + rect.nHeight - 1, videoDef->nFrameHeight);
./frameworks/base/media/libstagefright/OMXCodec.cpp:
status_t err = mOMX->getConfig(mNode, OMX_IndexConfigCommonOutputCrop,&rect, sizeof(rect));
CODEC_LOGI("video dimensions are %ld x %ld",video_def->nFrameWidth, video_def->nFrameHeight);
if (err == OK) {
#ifdef SAMSUNG_CODEC_SUPPORT
/* Hack GetConfig */
rect.nLeft = 0;
rect.nTop = 0;
rect.nWidth = video_def->nFrameWidth;
rect.nHeight = video_def->nFrameHeight;
#endif
CHECK_GE(rect.nLeft, 0);
CHECK_GE(rect.nTop, 0);
CHECK_GE(rect.nWidth, 0u);
CHECK_GE(rect.nHeight, 0u);
CHECK_LE(rect.nLeft + rect.nWidth - 1, video_def->nFrameWidth);
CHECK_LE(rect.nTop + rect.nHeight - 1, video_def->nFrameHeight);
mOutputFormat->setRect(kKeyCropRect,rect.nLeft,rect.nTop,rect.nLeft + rect.nWidth - 1,rect.nTop + rect.nHeight - 1);
CODEC_LOGI("Crop rect is %ld x %ld @ (%ld, %ld)",rect.nWidth, rect.nHeight, rect.nLeft, rect.nTop);
} else {
mOutputFormat->setRect(kKeyCropRect,0, 0,video_def->nFrameWidth - 1,video_def->nFrameHeight - 1);
}
I think we can safely ignore this failure for now.
get_extension_index might be a little more tricky. The file vendor/qcom/opensource/omx/mm-video/vidc/vdec/src/omx_vdec.cpp is a video decoder and the code for the get_extension_index is:
OMX_ERRORTYPE omx_vdec::get_extension_index(OMX_IN OMX_HANDLETYPE hComp,OMX_IN OMX_STRING paramName,OMX_OUT OMX_INDEXTYPE* indexType)
{
if(m_state == OMX_StateInvalid)
{
DEBUG_PRINT_ERROR("Get Extension Index in Invalid State\n");
return OMX_ErrorInvalidState;
}
else if (!strncmp(paramName, "OMX.QCOM.index.param.video.SyncFrameDecodingMode" ,sizeof("OMX.QCOM.index.param.video.SyncFrameDecod ingMode") - 1)) {
*indexType = (OMX_INDEXTYPE)OMX_QcomIndexParamVideoSyncFrameDec odingMode;
}
#ifdef MAX_RES_1080P
else if (!strncmp(paramName, "OMX.QCOM.index.param.IndexExtraData",sizeof("OMX. QCOM.index.param.IndexExtraData") - 1))
{
*indexType = (OMX_INDEXTYPE)OMX_QcomIndexParamIndexExtraDataTyp e;
}
#endif
#if defined (_ANDROID_HONEYCOMB_) || defined (_ANDROID_ICS_)
else if(!strncmp(paramName,"OMX.google.android.index.enableAndroidNativeBuffers", sizeof("OMX.google.android.index.enableAndroidNati veBuffers") - 1)) {
*indexType = (OMX_INDEXTYPE)OMX_GoogleAndroidIndexEnableAndroid NativeBuffers;
}
else if(!strncmp(paramName,"OMX.google.android.index.useAndroidNativeBuffer2", sizeof("OMX.google.android.index.enableAndroidNati veBuffer2") - 1)) {
*indexType = (OMX_INDEXTYPE)OMX_GoogleAndroidIndexUseAndroidNat iveBuffer2;
}
else if(!strncmp(paramName,"OMX.google.android.index.useAndroidNativeBuffer", sizeof("OMX.google.android.index.enableAndroidNati veBuffer") - 1)) {
DEBUG_PRINT_ERROR("Extension: %s is supported\n", paramName);
*indexType = (OMX_INDEXTYPE)OMX_GoogleAndroidIndexUseAndroidNat iveBuffer;
}
else if(!strncmp(paramName,"OMX.google.android.index.getAndroidNativeBufferUsage", sizeof("OMX.google.android.index.getAndroidNativeB ufferUsage") - 1)) {
*indexType = (OMX_INDEXTYPE)OMX_GoogleAndroidIndexGetAndroidNat iveBufferUsage;
}
#endif
else {
DEBUG_PRINT_ERROR("Extension: %s not implemented\n", paramName);
return OMX_ErrorNotImplemented;
}
return OMX_ErrorNone;
}
In the debug output the message "OMX_GetExtensionIndex failed" comes from frameworks/base/media/libstagefright/omx/OMXNodeInstance.cpp:
status_t OMXNodeInstance::enableGraphicBuffers(OMX_U32 portIndex, OMX_BOOL enable) {
Mutex::Autolock autoLock(mLock);
OMX_INDEXTYPE index;
OMX_ERRORTYPE err = OMX_GetExtensionIndex(mHandle,const_cast<OMX_STRING>("OMX.google.android.index.e nableAndroidNativeBuffers"),&index);
if (err != OMX_ErrorNone) {
LOGE("OMX_GetExtensionIndex failed");
return StatusFromOMXError(err);
}
OMX_VERSIONTYPE ver;
ver.s.nVersionMajor = 1;
ver.s.nVersionMinor = 0;
ver.s.nRevision = 0;
ver.s.nStep = 0;
EnableAndroidNativeBuffersParams params = {
sizeof(EnableAndroidNativeBuffersParams), ver, portIndex, enable,
};
err = OMX_SetParameter(mHandle, index, &params);
if (err != OMX_ErrorNone) {
LOGE("OMX_EnableAndroidNativeBuffers failed with error %d (0x%08x)", err, err);
return UNKNOWN_ERROR;
}
return OK;
}
So the OMX.google.android.index.enableAndroidNativeBuffers extension is the one we are missing, from the code snippet above this, we can see an
#if defined (_ANDROID_HONEYCOMB_) || defined (_ANDROID_ICS_)
#endif
around the check for this extension, so it has been added since Gingerbread, a diff with the cm7 source tells us that the enableGraphicsBuffers has also been added since gingerbread. The header file /frameworks/base/include/media/stagefright/HardwareAPI.h contains the following:
// A pointer to this struct is passed to the OMX_SetParameter when the extension
// index for the 'OMX.google.android.index.enableAndroidNativeBuffers' extension
// is given.
//
// When Android native buffer use is disabled for a port (the default state),
// the OMX node should operate as normal, and expect UseBuffer calls to set its
// buffers. This is the mode that will be used when CPU access to the buffer is
// required.
//
// When Android native buffer use has been enabled for a given port, the video
// color format for the port is to be interpreted as an Android pixel format
// rather than an OMX color format. The node should then expect to receive
// UseAndroidNativeBuffer calls (via OMX_SetParameter) rather than UseBuffer
// calls for that port.
struct EnableAndroidNativeBuffersParams {
OMX_U32 nSize;
OMX_VERSIONTYPE nVersion;
OMX_U32 nPortIndex;
OMX_BOOL enable;
};
I doubt the gb codec that we do have has support for the Android pixel format.
This gives us two options 1) can we change the stagefright sources to support both, i.e. if the extension OMX.google.android.index.enableAndroidNativeBuffers isn't supported then do what was done in gb.
or 2) write a wrapper for the GB codec that we do have doing the pixel format conversion in software. This again should work, after all the generic gb stagefright code had to do it on gingerbread so it must be possible.
I think option 2 will be the best bet since we will not change any of the generic code to do it. First step will be to create a wrapper that does nothing, but wraps the current codec, then hopefully we can use the various opensource drivers to work out what needs to be done to get our wrapper to work.
This information is all for Decode drivers, this approach might be possible with the encoding driver too, but I have done very little research into that.

It's good that someone is doing research on this............
I think this might help
http://limoa.sourceforge.net/
Click to expand...
Click to collapse
P.S.-You should consult all the people developing ICS for their respective ARMv6 devices
P.S.2-Submitted to portal

Our hardware has MDP 3.0.2 and you need at least MDP 4.0 for the OMX stuff. You need new hardware for this and qcom will for sure not investigate a lot of money for old and dead hardware.

An idea of some wrapper around the GB codecs sounds good, but wouldn't the CPU be eaten doing this?

i think it will be better than nothing (like now)

modpunk said:
Our hardware has MDP 3.0.2 and you need at least MDP 4.0 for the OMX stuff. You need new hardware for this and qcom will for sure not investigate a lot of money for old and dead hardware.
Click to expand...
Click to collapse
I have to admit that I know very little about the abilities of our hardware, and given your excellent work on this ROM I'm sure you know much more, however, our hardware CAN play videos using hardware OMX drivers on Gingerbread why specifically do you think that the hardware wouldn't be up to it on ICS ?

benjamingwynn said:
An idea of some wrapper around the GB codecs sounds good, but wouldn't the CPU be eaten doing this?
Click to expand...
Click to collapse
Well, that might well be the problem, however, I have two thoughts on this:
1) Doing some of the decode in hardware and some in software should be better than all in software (depending on the hoops we have to jump through to get the APIs to match).
2) GB must be converting the output of the GB OMX drivers into some kind of native buffer so that it can display the frames so that would indicate it should be possible.
In the end, until we try we won't find out.

scottrix said:
Well, that might well be the problem, however, I have two thoughts on this:
1) Doing some of the decode in hardware and some in software should be better than all in software (depending on the hoops we have to jump through to get the APIs to match).
2) GB must be converting the output of the GB OMX drivers into some kind of native buffer so that it can display the frames so that would indicate it should be possible.
In the end, until we try we won't find out.
Click to expand...
Click to collapse
Just wondering, I'm not the most profficient in coding and the like, but what kind of programmer *may* be able to create a script for something like this? Someone with Android SDK and Java experience, or is it C based?

Ko_Ka said:
Just wondering, I'm not the most profficient in coding and the like, but what kind of programmer *may* be able to create a script for something like this? Someone with Android SDK and Java experience, or is it C based?
Click to expand...
Click to collapse
Code is C / C++ look in vendor/qcom/opensource/omx

scottrix said:
Code is C / C++ look in vendor/qcom/opensource/omx
Click to expand...
Click to collapse
Well, I have had some time to play and I have decided to change the code:
vendor/qcom/opensource/omx/mm-core/omxcore/src/common/omx_core_cmp.cpp
this seems to be a wrapper around the OMX codec, just making my edits with ENABLE_GINGERBREAD_OMX_DRIVERS define. Would be nice to come up with a cleaner solution, i.e. one that doesn't need changes to CM source as I doubt we would get modifications upstream, but until I get something working, it will do.
I have got rid of the get_extension_index problem, and some set_parameter problems, however, the underlying driver is giving:
Set Parameter called in Invalid State
Which isn't good since we don't have the source to know why it thinks it is invalid. My next step is to trace through the CM7.2 and CM9 code to work out how they are configuring the OMX driver differently. I should probably point out that my first goal is to get the codec running, I expect the screen output to be incorrect and need some colour format conversion, but one step at a time.
I am currently only looking at Decode, does anyone know if encoding (taking videos with the camera) works with the GB codec (can use logcat to tell if it is using sofware or GB codec).
BTW, there is code in vendor/qcom/opensource, have we asked qcom if they would be prepared to opensource the GB codecs ? they have obivously done it before so might be interested.

Progress, well not quite, but I have found some more out. First in the code:
frameworks/base/media/libstagefright/OMXCodec.cpp
In the class constructor there is this code:
mNativeWindow(
(!strncmp(componentName, "OMX.google.", 11)
|| !strcmp(componentName, "OMX.Nvidia.mpeg2v.decode"))
? NULL : nativeWindow) {
If mNativeWindow is NULL then it doesn't do a get_extension_index for the nativebuffers and grepping the software codecs shows that these don't support it either. It's not the place in the code I wanted to start altering, but let's get something working first. So I added the qcom component name to this list and now get further...... but still no working video. I have been through the code from the component init to the point of failure:
I/OMXCodec( 106): [OMX.qcom.video.decoder.mpeg4] calling emptyBuffer with codec specific data
I/QC_CORE ( 106): OMXCORE: qc_omx_component_empty_this_buffer 1c894, 1f838
D/VCODEC omx_vdec( 106): omx_vdec::empty_this_buffer +
D/VCODEC omx_vdec( 106): omx_vdec::empty_this_buffer vdec_open +
D/VCODEC vdec( 106): vdec_open
W/VCODEC vdec( 106): vdec: failed to allocate pmem arena (5783552 bytes)
E/VCODEC vdec( 106): vendor/qcom/proprietary/qdsp5/mm-video/7k/7x27/vdec-omxmp4/../vdec-common/vdec.cpp:365 *** ERROR ASSERT(0)
and compared it to the cm7 code. I have also installed cm7 and compared the output from a logcat, and still no luck, I have found other differences, however, none have actually made a difference. next step is to output more tracing from cm7 and cm9 to determine if there are more differences. My worry is that there is something else on the system messing with this hardware and initializing it in a different way. Does anyone know if the adreno drivers use /dev/pmem ? as these have changed from cm7 to cm9.

Hm, maybe qcom tech support could help you with the /dev thing. It may sound dumb but qcom are pretty good with stuff like this.
Sent from my Wildfire S A510e using xda app-developers app

omx
You won't find omx in gingerbread.. it was one of ics's new implimentations to enable hardware accelleration. Tis why qualcom released updated firmware to aid devs porting to ics. Pretty much our luck ran out there. The petition died when 1)Qualcomm said omx codecs were not possible for our chips and 2)Arm pulled the old arm11 development layer down.. So, pretty much not possible. Basically as I understand it, it requires adv sim.d or what arm calls neon (or a msm7x27a chip.. we have msm 7x27)
What is possible is what you mentioned. Using gb binaries with a wrapper. This wrapper is called a HAL. Unfortunately, CM has stated the time investment to do this for each cortex a8 is not worth it (and may break cvs); so, their official support (if we should even be able to get it for our beleagured device) would end with gb. And thus ends my input for the evening.
Rob

insink71 said:
You won't find omx in gingerbread.. it was one of ics's new implimentations to enable hardware accelleration. Tis why qualcom released updated firmware to aid devs porting to ics. Pretty much our luck ran out there. The petition died when 1)Qualcomm said omx codecs were not possible for our chips and 2)Arm pulled the old arm11 development layer down.. So, pretty much not possible. Basically as I understand it, it requires adv sim.d or what arm calls neon (or a msm7x27a chip.. we have msm 7x27)
What is possible is what you mentioned. Using gb binaries with a wrapper. This wrapper is called a HAL. Unfortunately, CM has stated the time investment to do this for each cortex a8 is not worth it (and may break cvs); so, their official support (if we should even be able to get it for our beleagured device) would end with gb. And thus ends my input for the evening.
Rob
Click to expand...
Click to collapse
OMX IS in gingerbread (or at least CM7), in fact the requirements for it are cleaner than ICS, ICS requires some google specific extensions. There ARE OMX drivers for the msm7x27, but they don't support the google extensions and so don't work (although it is a little more complicated than that). CM has stated that they will not support ARM6 devices so even if we were to get drivers from Qualcom, CM would not support it. Just cos CM say they aren't going to support it doesn't mean that it is not possible to produce a great ROM, as Ben and Modpunk and others have already proven, if you are looking for a CM supported version then you will need to buy a new phone.
I've been a little busy with other things over the last week or so and hope to get back to this soon.
One question I do have is that if I were to use the GB Adreno drivers on the ICS ROM would the phone still boot ? what would be the problems I'd notice ? not thinking of this as a long term solution, but might help me figure out what is going on, if my current thoughts turn up nothing.
Scott.

scottrix said:
OMX IS in gingerbread (or at least CM7), in fact the requirements for it are cleaner than ICS, ICS requires some google specific extensions. There ARE OMX drivers for the msm7x27, but they don't support the google extensions and so don't work (although it is a little more complicated than that). CM has stated that they will not support ARM6 devices so even if we were to get drivers from Qualcom, CM would not support it. Just cos CM say they aren't going to support it doesn't mean that it is not possible to produce a great ROM, as Ben and Modpunk and others have already proven, if you are looking for a CM supported version then you will need to buy a new phone.
I've been a little busy with other things over the last week or so and hope to get back to this soon.
One question I do have is that if I were to use the GB Adreno drivers on the ICS ROM would the phone still boot ? what would be the problems I'd notice ? not thinking of this as a long term solution, but might help me figure out what is going on, if my current thoughts turn up nothing.
Scott.
Click to expand...
Click to collapse
If I remember correctly (I might be wrong here) using gingerbread drivers broke hardware acceleration.

benjamingwynn said:
If I remember correctly (I might be wrong here) using gingerbread drivers broke hardware acceleration.
Click to expand...
Click to collapse
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.

Hm this looks promising. The HTC hero uses adreno(?) 100 graphics whereas we use adreno 200, since qcom never released adreno 100 libs it'd be interesting to see how they got hwa on ics.
github.com/teamics
Sent from my Wildfire S A510e using xda app-developers app

benjamingwynn said:
Hm this looks promising. The HTC hero uses adreno(?) 100 graphics whereas we use adreno 200, since qcom never released adreno 100 libs it'd be interesting to see how they got hwa on ics.
github.com/teamics
Sent from my Wildfire S A510e using xda app-developers app
Click to expand...
Click to collapse
More importantly do the OMX drivers work on their build. If yes that would be worth looking into if not why bother, that automaticly eliminates the theory above.
Edit: I actualy looked that up myself and what i saw is Video playback does work on the Hero. However they havent goten HWA working. But thats what i got from the op on the CM9 and CM10 threads might be something im missing. But this seems to prove the theory about ICS libs stoping omx from working on our device. The question becomes now will it ever be possible to have them both working ?

baluuu said:
More importantly do the OMX drivers work on their build. If yes that would be worth looking into if not why bother, that automaticly eliminates the theory above.
Edit: I actualy looked that up myself and what i saw is Video playback does work on the Hero. However they havent goten HWA working. But thats what i got from the op on the CM9 and CM10 threads might be something im missing. But this seems to prove the theory about ICS libs stoping omx from working on our device. The question becomes now will it ever be possible to have them both working ?
Click to expand...
Click to collapse
Looking at the Hero threads it seems that HQ video isn't working either. Does any one know different ?.

scottrix said:
Looking at the Hero threads it seems that HQ video isn't working either. Does any one know different ?.
Click to expand...
Click to collapse
May I add some input?
Eoghan2t7, who's working on porting Firefox OS aka B2G, has looked at the files and has noticed that even though B2G is based off ICS, it uses the Gingerbread OMX libs. Now, we need to see of there's some code wrapped up around it, which allows the GB libs to work on ICS.
If we get that code (if it does exist) then our problem may have been solved.
Here's his quote:
eoghan2t7 said:
hi everyone so far my attempts on getting this to build have not worked so i am going to taking a break at trying to fix the build errors and start reading up on github of ports already done to see what commits are needed etc. i am also puzzled to why the b2g seems to use the gingerbread omx files instead of using the omx files from AOSP ICS so ill be looking into that as well incase there are some code added to it to allow the GB libs to work on ICS since b2g is based off ICS
Click to expand...
Click to collapse
Sent from my HTC Wildfire S using xda premium

[BETA] AGPS fix for HTC One X - Andorid Revolution 18.1 ONLY

BE WARNED​
THIS PATCH WILL ONLY WORK ON​
MIKE'S ROM (Android_Revolution_HD-One_X_18.1)​
This patch will currently only work for the "Android_Revolution_HD-One_X_18.1" ROM because within this patch there is a modified build.prop. When you have done changes or custom settings on this ROM within the build.prop they will be lost and revert back to mike's defaults.
1. What damn changes?
I have add the value
ro.ril.def.agps.mode=2
Click to expand...
Click to collapse
to the build.prop
This should be required for enable AGPS by default. Not sure if this is true but on the one hand it seems to work and on the other hand this is a BETA patch.
2. Show the content of the gps.conf
This is the gps.conf within this patch:
NTP_SERVER=de.pool.ntp.org
AGPS=/data/xtra.bin
AGPS=http://xtra1.gpsonextra.net/xtra.bin
XTRA_SERVER_1=/data/xtra.bin
XTRA_SERVER_2=http://xtra2.gpsonextra.net/xtra.bin
XTRA_SERVER_3=http://xtra3.gpsonextra.net/xtra.bin
GPS1_CLEANUP_ENABLED=1
GPS1_SESSION_TIMEOUT=2
GPS1_XTRA_AUTO_DOWNLOAD_ENABLED=1
GPS1_XTRA_DOWNLOAD_INTERVAL=6
INTERMEDIATE_POS=1
ACCURACY_THRES=5000
ACCURACY_THRES=100
ENABLE_WIPER=1
CURRENT_CARRIER=common
PHONE_TYPE=UMTS
DEFAULT_AGPS_ENABLE=TRUE
DEFAULT_SSL_ENABLE=FALSE
DEFAULT_USER_PLANE=TRUE
REPORT_POSITION_USE_SUPL_REFLOC=1
QOS_ACCURACY=50
QOS_TIME_OUT_STANDALONE=60
QOS_TIME_OUT_agps=89
QosHorizontalThreshold=1000
QosVerticalThreshold=500
SUPL_HOST=supl.google.com
SUPL_PORT=7276
SUPL_SECURE_PORT=7275
SUPL_NO_SECURE_PORT=3425
SUPL_TLS_HOST=FQDN
SUPL_TLS_CERT=/etc/SuplRootCert
C2K_HOST=c2k.pde.com
C2K_PORT=7275
#UserParam
AssistMethodType=1
AgpsUse=1
AgpsMtConf=0
AgpsMtResponseType=1
AgpsServerType=1
AgpsServerIp=3232235555
AgpsServerPort=7276
AgpsServerFqdnType=1
AgpsServerFqdnStr=supl.google.com
AgpsSecureSocketOn=1
GpsPlusAutoDownloadOn=1
PdrEnable=1
WpsPdrEnable=1
LocationEnable=1
NetworkLocationEnable=1
use_logcat = 1
event_mask = 65535
nmea_sentence_mask = 31
# 1 = no lock (who the hell has coded this??)
engine_lock = 1
operation_mode = 4
fix_session_type = 0
time_between_fixes = 60
accuracy_threshold = 255
fix_timeout = 60
#XTRA related parameters
enable_auto_download = 1
auto_download_period = 1
#xtra1.gpsonextra.net
xtra_server_addr = 216.187.118.37
data_request_reply = 0
umts_profile_number = 0
apn_name = NULL
GpsMode=2
GpsOption=4
SessonType=2
QosTimeout=255
DataReceiveType=1
DeviceType=3
SensorMagneticOn=0
#TestParam
ULTSOn=0
#NetworkParam
IndexOfApn=3
#GpsPlusInfo
XtraDataSetTime=0
GpsPlusSetTime=-796640328
Click to expand...
Click to collapse
If you have additional parameters or other recommendations, please feel so free and submit this here.
3. How to test?
I have this configuration on my HTC running and it was a need to wait and also to travel arround to get an exact result. I was only Google Maps using and testing. If you have different Navigation Systems installed please also check and test this.
4. How fast?
GPS lock takes 1 to 3 seconds - than it's done. WiFi is also enabled so it doesn't matters if you are using UMTS/GPRS or WiFi.
5. Bugs?
Yes. At the moment it takes some time until you get the first exact result. At the moment it is only between 3 to 10 meteres exactly.
6. Goal?
I want to have a real 99,995% result and want to get a result with a different of max. 1 meter.
For this it would be great if you can give a Feedback please. Thanks!!

Help-me!
MrT69 said:
BE WARNED​
THIS PATCH WILL ONLY WORK ON​
MIKE'S ROM (Android_Revolution_HD-One_X_18.1)​
This patch will currently only work for the "Android_Revolution_HD-One_X_18.1" ROM because within this patch there is a modified build.prop. When you have done changes or custom settings on this ROM within the build.prop they will be lost and revert back to mike's defaults.
1. What damn changes?
I have add the value
to the build.prop
This should be required for enable AGPS by default. Not sure if this is true but on the one hand it seems to work and on the other hand this is a BETA patch.
2. Show the content of the gps.conf
This is the gps.conf within this patch:
If you have additional parameters or other recommendations, please feel so free and submit this here.
3. How to test?
I have this configuration on my HTC running and it was a need to wait and also to travel arround to get an exact result. I was only Google Maps using and testing. If you have different Navigation Systems installed please also check and test this.
4. How fast?
GPS lock takes 1 to 3 seconds - than it's done. WiFi is also enabled so it doesn't matters if you are using UMTS/GPRS or WiFi.
5. Bugs?
Yes. At the moment it takes some time until you get the first exact result. At the moment it is only between 3 to 10 meteres exactly.
6. Goal?
I want to have a real 99,995% result and want to get a result with a different of max. 1 meter.
For this it would be great if you can give a Feedback please. Thanks!!
Click to expand...
Click to collapse
Friend! I'm currently with Android Rom Revolutions 18.1. I did the tests off the wifi and data and then immediately turned the Sygic which took about 4 seconds to find my location. Do you think I should do some correction? : Confuso:

4 seconds to find your location? Is this bad or is this good?

I'm on 4.2 AOKP Rom and changed the files by hand to your Version. My GPS Works much better now.
My Lock Time on AOKP was 4 - 10 Minutes. With your Version i've got 1 - 2 Minutes on first Lock and 2 - 10 seconds on each relock!
:victory:

Great! Glad to read this
Sent from my EndeavorU using xda app-developers app

{ZL}[DEVELOPMENT] - CM10.1 - Android 4.2.2 - FreeXperia Project

CyanogenMod is a free, community built distribution of Android 4.2 (Jelly Bean) which greatly extends the capabilities of your phone.
Code:
#include <std_disclaimer.h>
/*
* Your warranty is now void.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
*/

HOWTO
Install instructions:
first time
- power off the phone:
- hold vol+ and plug usb to boot into fastboot (blu led)
- fastboot flash boot boot.img (from cm10 zip)
- fastboot reboot
- enter recovery, on boot led will be violet for 3'', during this period press vol+
- flash rom zip
- flash gapps zip
- wipe
- reboot
for update just flash rom zip from recovery
Google Apps are not included in this ROM. You'll need to find those yourself if you want them.
ENJOY AN UNOFFICIAL CM10 RELEASE BROUGHT TO YOU BY FreeXperia Team
PLEASE DONT MIRROR OUR ROMS
DOWNLOAD
http://unrestrict.li/FXP

thanks to all who made this possible supporting us
contributing with code, donations or even trusting us
thanks to SONY that made all this possible !

Could you post the things not working in the CM... It would help infinding out whether it is usable for daily use... Thanks!!

shivindera said:
Could you post the things not working in the CM... It would help infinding out whether it is usable for daily use... Thanks!!
Click to expand...
Click to collapse
You can see it here: https://sites.google.com/site/projectfreexperia/known-bugs/supported-device/cm-10-1-fusion3

FXP210 released

This phone hasn't released anywhere yet, and hence no interest.

I think you need to post direct links to the download for your roms... Cause the link you provide takes us to downloads which doesnt even say what phone they are for...

hyelton said:
I think you need to post direct links to the download for your roms... Cause the link you provide takes us to downloads which doesnt even say what phone they are for...
Click to expand...
Click to collapse
http://unrestrict.li/FXP
download this one:
FXP210_cm-10.1-20130310-UNOFFICIAL-odin.zip
odin is name of this device...

DooMLoRD said:
http://unrestrict.li/FXP
download this one:
FXP210_cm-10.1-20130310-UNOFFICIAL-odin.zip
odin is name of this device...
Click to expand...
Click to collapse
Oh okay its just kind of confusing haha. When I seen odin i thought of Samsung.

FXP211 released

Firstly, thanks for the great ROM.
Secondly, I'd like to report an issue. Everything runs pretty smoothly for me; however, one issue bugs me a lot: slow wake up and sleep.
By wake up, I mean the time it takes for the lock screen to appear after I press the power button and by sleep I mean the screen turning off.
It takes around 500ms, which is much longer than it took my previous Xperia U on CM9 and this phone on a stock ROM.
Here's a little logcat where you can see that even the phone reports that it is lagging (the first part is wake up and the second part is sleep):
Code:
D/DASH ( 725): hardware/sony/DASH/sensors_wrapper.c(227): sensors_wrapper_activate: lock
I/PowerManagerService( 725): Waking up from sleep...
E/ANDR-PERF-MPCTL( 725): MPCTL client send 3
E/ANDR-PERF-MPCTL( 225): Received len=92, m=1297100099, v=2, c=725, s=97, m=604776608 (0x240c28a0) d=0
I/QCOM PowerHAL( 725): Perflock released.
D/SurfaceFlinger( 212): Screen acquired, type=0 flinger=0x405633a8
D/qdhwcomposer( 212): hwc_blank: Unblanking display: 0
D/DASH ( 725): hardware/sony/DASH/sensors_wrapper.c(253): sensors_wrapper_activate: unlock
D/DASH ( 725): hardware/sony/DASH/sensors_wrapper.c(269): sensors_wrapper_set_delay: lock
D/DASH ( 725): hardware/sony/DASH/sensors_wrapper.c(281): sensors_wrapper_set_delay: unlock
D/DASH ( 725): hardware/sony/DASH/sensors_wrapper.c(269): sensors_wrapper_set_delay: lock
D/DASH ( 725): hardware/sony/DASH/sensors_wrapper.c(281): sensors_wrapper_set_delay: unlock
I/WindowManager( 725): Lock screen displayed!
D/qdhwcomposer( 212): hwc_blank: Done unblanking display: 0
[B]D/Surface ( 725): Excessive delay in unblankDisplay() while turning screen on: 326ms[/B]
I/PowerManagerService( 725): Going to sleep by user request...
D/SurfaceFlinger( 212): Screen released, type=0 flinger=0x405633a8
D/qdhwcomposer( 212): hwc_blank: Blanking display: 0
D/DASH ( 725): hardware/sony/DASH/sensors_wrapper.c(227): sensors_wrapper_activate: lock
D/DASH ( 725): hardware/sony/DASH/sensors_wrapper.c(253): sensors_wrapper_activate: unlock
D/DASH ( 725): hardware/sony/DASH/sensors_wrapper.c(269): sensors_wrapper_set_delay: lock
D/DASH ( 725): hardware/sony/DASH/sensors_wrapper.c(281): sensors_wrapper_set_delay: unlock
V/KeyguardHostView( 725): Keyguard widgets disabled by DPM
V/KeyguardHostView( 725): Keyguard secure camera disabled by DPM
E/KeyguardHostView( 725): Error when trying to bind default AppWidget: java.lang.IllegalArgumentException: not a appwidget provider: ComponentInfo{/}
D/dalvikvm( 725): GC_CONCURRENT freed 5374K, 37% free 15440K/24148K, paused 4ms+9ms, total 77ms
D/dalvikvm( 725): WAIT_FOR_CONCURRENT_GC blocked 53ms
D/qdhwcomposer( 212): hwc_blank: Done blanking display: 0
[B]D/Surface ( 725): Excessive delay in blankDisplay() while turning screen off: 325ms[/B]
E/ANDR-PERF-MPCTL( 725): MPCTL client send 2
E/ANDR-PERF-MPCTL( 225): Received len=92, m=1297100099, v=2, c=725, s=98, m=1925311322 (0x72c1eb5a) d=1

Do we just have to do a cache/ dalvik wipe or entire data wipe in recovery if coming from a different (stock) rom? On samsung/ google devices I know it would be a complete data wipe, but since I am new to the xperia line, I dont know if things are different

anirudh412 said:
Do we just have to do a cache/ dalvik wipe or entire data wipe in recovery if coming from a different (stock) rom? On samsung/ google devices I know it would be a complete data wipe, but since I am new to the xperia line, I dont know if things are different
Click to expand...
Click to collapse
complete wipe always
stock ROM obviously has a different set of apps storing a different set of databases in a different way which will hinder the way AOSP apps store data.
so yes, wipe

like this rom but dont wanna unlock BL, dont wanna lose MBE2 and some features

sonic2911 said:
like this rom but dont wanna unlock BL, dont wanna lose MBE2 and some features
Click to expand...
Click to collapse
Losing of MBE2 is up for debate. I used my ZL with a locked BL for a week and am now rocking it with an unlocked BL. I might be blind, but I don't see any difference while watching movies or pics. If there is a difference, it is very subtle and is not noticeable unless one compares two phones side by side. Even if there is, the tradeoff is something I don't mind. Now I can feed my flash addiction. AOKP here I come

AW: {ZL}[DEVELOPMENT] - CM10.1 - Android 4.2.2 - FreeXperia Project
On LG 2x-Section there are several roms which include the sony bravia engine 2, so I think if you loose it, it can be restored.

Does anyone have a mirror or a torrent link? The ones provided in the OP are painfully slow. And yes, I have checked my network speeds, they are just fine :good:
TIA

FXP213 released

Flashed the 213 for Odin. No network reception?! Does anyone have this problem? Did as mentioned, flashed boot.img in fastboot, flashed the ROM in recovery. Havent flashed the GAPPS yet though, but I dont think that should matter?