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, ¶ms);
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
Related
A simple photochooser task application throws a Nullrefference exception(Invalid pointer) and pixel height and width is 0 on mango, on nodo it worked alright.
Am I missing a cast? or this is a bug in mango, and will be fixed?
Here's the code:
Code:
private PhotoChooserTask photo;
// Constructor
public MainPage()
{
InitializeComponent();
photo = new PhotoChooserTask();
photo.Completed += new EventHandler<PhotoResult>(photo_Completed);
}
void photo_Completed(object sender, PhotoResult e)
{
if (e.TaskResult == TaskResult.OK)
{
BitmapImage bi = new BitmapImage();
bi.SetSource(e.ChosenPhoto);
//////////////////////////////////////////////////////////////////////////////////////
var wb = new WriteableBitmap(bi);//Exception here
/////////////////////////////////////////////////////////////////////////////////////
// bi.PixelHeight and bi.PixelWidth == 0;
}
}
private void button1_Click(object sender, RoutedEventArgs e)
{
photo.Show();
}
}
Hope someone can help.
Thanks in advance
This is because you need to set the CreateOptions property of the BitmapImage before you use it to construct the WriteableBitmap.
The default 'create' option on WP7 is DelayCreation (it may be BackgroundCreation in some of the 7.1 betas, but the mango RTM I think is DelayCreation) but either way the problem you're having is that your image has not been initialised yet at the point you use it in the WriteableBitmap's constructor (hence the null reference exception).
The options (depending what you set) let images be only initialised when needed, and downloaded on separate threads / asynchronously, which can help performance (or at least stop the phone blocking other things happening whilst images are loaded). Users also have the ability with the photo chooser to pick images from online ablums, so as you can imagine you also have to handle perhaps a second or two waiting for a download to complete, and of course downloads can also fail when connections drop etc. which you can handle too.
So in answer to your question (off the top of my head, not confirmed it with code) set the createoptions to none, and use the Bitmap's ImageOpened event to construct the WritableBitmap (you may also want to handle the Bitmap's ImageFailed event). Make sure you set up the ImageOpened event before you set the source, i.e.
BitmapImage bi = new BitmapImage();
bi.CreateOptions = BitmapCreateOptions.None;
bi.ImageOpened += new (some event name)
bi.ImageFailed += new (some event name)
bi.SetSource(e.ChosenPhoto);
Hope that helps,
Ian
Thank you very much
Problem solved
otherworld said:
This is because you need to set the CreateOptions property of the BitmapImage before you use it to construct the WriteableBitmap.
The default 'create' option on WP7 is DelayCreation (it may be BackgroundCreation in some of the 7.1 betas, but the mango RTM I think is DelayCreation) but either way the problem you're having is that your image has not been initialised yet at the point you use it in the WriteableBitmap's constructor (hence the null reference exception).
The options (depending what you set) let images be only initialised when needed, and downloaded on separate threads / asynchronously, which can help performance (or at least stop the phone blocking other things happening whilst images are loaded). Users also have the ability with the photo chooser to pick images from online ablums, so as you can imagine you also have to handle perhaps a second or two waiting for a download to complete, and of course downloads can also fail when connections drop etc. which you can handle too.
So in answer to your question (off the top of my head, not confirmed it with code) set the createoptions to none, and use the Bitmap's ImageOpened event to construct the WritableBitmap (you may also want to handle the Bitmap's ImageFailed event). Make sure you set up the ImageOpened event before you set the source, i.e.
BitmapImage bi = new BitmapImage();
bi.CreateOptions = BitmapCreateOptions.None;
bi.ImageOpened += new (some event name)
bi.ImageFailed += new (some event name)
bi.SetSource(e.ChosenPhoto);
Hope that helps,
Ian
Click to expand...
Click to collapse
Hello, I have the same problem (NullReferenceException) and have read you response, which from what I see it is the solution, but I have a problem; not where I have to go to do I change them that you propose. I would be so kind of explaining to me that I have to continue steps. It English me is very bad and I am using a translator.
I have HTC Trophy the v.th 7740.16 with chevrom and U2M7740 of Ansar.
Thank you in advance and greetings.
Hi,
If you upload your code / project I will take a look and see where the error is.
Si me muestras su código / proyecto, puedo ver por qué recibiras una excepción NullReference
Ian
otherworld said:
Hi,
If you upload your code / project I will take a look and see where the error is.
Si me muestras su código / proyecto, puedo ver por qué recibiras una excepción NullReference
Ian
Click to expand...
Click to collapse
Hello,
The question is that it is not any project, applications do not develop (although I would like). This type of errorr (nullreferenceexception) happens to me since I updated to Mango, so much in v.7720.68 as in v.7740.16 and happens in apps as Morfo, Fantasy Painter, and at the time of choosing fund in Touchxperience. Not if these apps are not conditioned to Mango or if, perhaps, from the record it might change some type of configuration or entering the Xaml of the app to be able to change some fact, end not...
For the little that, an error of the photochooser seems to be, the question is if it is possible to gain access to him and as doing it.
Anyhow thank you very much and a cordial greeting.
Hi,
If it is not a code issue then I do not know what it could be. Are you using a custom rom?
Good luck with it.
Ian
otherworld said:
Hi,
If it is not a code issue then I do not know what it could be. Are you using a custom rom?
Good luck with it.
Ian
Click to expand...
Click to collapse
Hello. Not, I am with official Mango the v.th 7740.16. I have already restored to factory and it continues the error. I believe that it is a question of the update, it must have a mistake in the pitcher of photos or some error with the librerie, do not know...
Thank you anyhow and greetings.
Hello, otherworld.
I continue with the same problem, 'nullreferenceexception' related with 'chooserphoto' in some application. The curious thing is that someone of them me work correctly, I gain access to me librery and it takes the photos, and in others not, as for example Morfo. I do not know if the problem is in the code source of these applications or phone is in me. Is this the code source of Morfo, is it possible to correct so that this does not happen?
Thank you in advance and greetings.
Today I found very annoying and strange bug (or, may be, MS call it "feature" ). Seems like directories on isf can hold 1024 files only...
Try code below:
Code:
Random rnd = new Random();
using (var isf = IsolatedStorageFile.GetUserStoreForApplication())
{
byte[] data = new byte[1024];
isf.CreateDirectory("test");
for (int i=0; i<1025; i++)
{
string fileName = "test\\" + i.ToString("D4") + ".bin";
using (IsolatedStorageFileStream fs = new IsolatedStorageFileStream(fileName, FileMode.Create, isf))
{
rnd.NextBytes(data);
fs.Write(data, 0, data.Length);
}
}
}
After loop completed, resulting directory "test" will be empty! But change i<1024 and you'll get all yours 1024 files...
Tested on emulator and HTC Surround, same results. Can't find any documentation about this limitation... Shame on you, MS!
Update: another strange behavior ('cause of this bug) - if you already have 1024 files and try to add one more, the whole directory content is "magically" disappear But exception isn't thrown...
Interesting, I'll try it as well. This would be lame to have to work around.
Dbeattie said:
Interesting, I'll try it as well.
Click to expand...
Click to collapse
Yes, please, confirm...
I can't test this at the moment but I know I write well over 1000 files to /shared/media so I'm curious to tet this.
sensboston said:
Yes, please, confirm...
Click to expand...
Click to collapse
Hey just tried it out, wrote 2k items to a folder called "Data".
While it didn't show up in the Windows Phone Power tools, the file does exist in the folder itself.
bool success = storage.FileExists(Path.Combine("data", "1999"));
So it's either a problem with the WPConnect api or with the power tools, haven't tried the command line tool.
Yep, fortunately you are right, it's a ISETool.exe (or drivers) bug, not a WP7 ISF.
sensboston said:
Yep, fortunately you are right, it's a ISETool.exe (or drivers) bug, not a WP7 ISF.
Click to expand...
Click to collapse
Could you therefore edit the title of the thread please?
Thanks.
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?
This is an experiment - project. It is about adding off-mode alarm clock to the HD2.
(If you don't have cLK installed (at least v1.5.1.4), then this is not applicable for you)
kokotas said:
Is it even possible to include something like auto-power-on in cLK, for alarm clock purposes?
Click to expand...
Click to collapse
After ~10 months, zicoxx asked more or less the same thing:
zicoxx said:
i want to suggest a feature for clk and our hd2..offline alarms
Click to expand...
Click to collapse
So lets see what we have so far...
This project depends on 3 factors, (1)Kernel, (2)Android application, (3)Bootloader.
Kernel
The kernel has a function in arch\arm\mach-msm\pm.c which handles the reboot reason:
Code:
static int msm_reboot_call(struct notifier_block *this, unsigned long code, void *_cmd)
{
if((code == SYS_RESTART) && _cmd) {
char *cmd = _cmd;
if (!strcmp(cmd, "bootloader")) {
restart_reason = 0x77665500;
} else if (!strcmp(cmd, "recovery")) {
restart_reason = 0x77665502;
} else if (!strcmp(cmd, "eraseflash")) {
restart_reason = 0x776655EF;
} else if (!strncmp(cmd, "oem-", 4)) {
unsigned code = simple_strtoul(cmd + 4, 0, 16) & 0xff;
restart_reason = 0x6f656d00 | code;
[COLOR="YellowGreen"]
//This is the proposed patch to our kernel
//(thanks Rick_1995 for suggesting it to bypass the time limit of 255 min)
} else if (!strncmp(cmd, "S", 1)) {
unsigned code = simple_strtoul(cmd + 1, 0, 16) & 0x00ffffff;
restart_reason = 0x53000000 | code;
[/COLOR]
} else if (!strcmp(cmd, "force-hard")) {
restart_reason = 0x776655AA;
} else {
restart_reason = 0x77665501;
}
}
return NOTIFY_DONE;
}
Not being able to compile a new kernel with a change like the green text in the above function, I just used the "oem-" prefix in the reboot reason passed from the application. The downside of this is that we can't set an alarm for more than 255 min from the current time.
Application
The application is able to:
reboot the device using the PowerManager class since it is signed and placed in /system/app:
Code:
//MinutesToSuspend is set using a TimePicker
mPowerManager.reboot("oem-" + MinutesToSuspend);
[COLOR="YellowGreen"]
//In case we have a kernel with the above patch included
mPowerManager.reboot("S" + MinutesToSuspend);[/COLOR]
play the alarm when the device has booted usind the BroadcastReceiver class that will get the BOOT_COMPLETED action.
Bootloader
The bootloader (in this case cLK):
detects the boot reason and decodes the MinutesToSuspend from it and enters a sort of suspend mode with a timeout equal to MinutesToSuspend converted to msec
Code:
if(target_check_reboot_mode() == (target_check_reboot_mode() | 0x6f656d00)) {
char str[16];
char *endptr;
unsigned MinutesToSuspend;
unsigned msecToSuspend = 0;
// Decode the MinutesToSuspend from the reboot_mode
sprintf(str, "%i", (target_check_reboot_mode() ^ 0x6f656d00));
MinutesToSuspend = strtol(str, &endptr, 16);
if (MinutesToSuspend < 3)
msecToSuspend = (MinutesToSuspend * 60000);
else
msecToSuspend = (MinutesToSuspend * 60000) - (120000);
suspend_time = msecToSuspend;
show_multi_boot_screen = 0;
boot_into_recovery = 0;
}
[COLOR="YellowGreen"]
//In case we have a kernel with the above patch included
#define MARK_ALARM_TAG 0x53000000
if(target_check_reboot_mode() & 0xFF000000 == MARK_ALARM_TAG) {
uint32_t MinutesToSuspend;
// Decode the MinutesToSuspend from the reboot_mode
MinutesToSuspend = target_check_reboot_mode() ^ MARK_ALARM_TAG;
if (MinutesToSuspend > 3)
MinutesToSuspend -= 2;
suspend_time = MinutesToSuspend * 60000;
show_multi_boot_screen = 0;
boot_into_recovery = 0;
}
[/COLOR]
if(suspend_time) {
msm_acpu_clock_init(1); // 384MHz (acpu_freq_tbl[0])
//Could try setting cpu clock at 245...
//msm_acpu_clock_init(0); // 245MHz (acpu_freq_tbl[0])
htcleo_suspend(suspend_time);
}
the suspend mode is implemented using this function
Code:
#define DS2746_SAFE_CHG_VOLTAGE 4200 // mV
void htcleo_suspend(unsigned timeout)
{
uint32_t voltage;
//int16_t current;
bool usb_cable_connected;
time_t start_time;
start_time = current_time();
if (timeout)
htcleo_panel_bkl_pwr(0);
do {
//current = ds2746_current(DS2746_I2C_SLAVE_ADDR, 1200);
voltage = ds2746_voltage(DS2746_I2C_SLAVE_ADDR);
usb_cable_connected = htcleo_usb_online();
if (usb_cable_connected) {
if (voltage < DS2746_SAFE_CHG_VOLTAGE) {
// If battery needs charging, set new charger state
if (htcleo_ac_online()) {
if (htcleo_charger_state() != CHG_AC ) {
writel(0x00080000, USB_USBCMD);
ulpi_write(0x48, 0x04);
htcleo_set_charger(CHG_AC);
}
} else {
if (htcleo_charger_state() != CHG_USB_LOW ) {
writel(0x00080001, USB_USBCMD);
mdelay(10);
htcleo_set_charger(CHG_USB_LOW);
}
}
// Led = solid amber
if (htcleo_notif_led_mode != 2)
thread_resume(thread_create("htcleo_notif_led_set_mode_2",
&htcleo_notif_led_set_mode,
(void *)2,
HIGH_PRIORITY,
DEFAULT_STACK_SIZE));
} else {
// Battery is full
if(timeout) {
// Set charger state to CHG_OFF_FULL_BAT
if (htcleo_charger_state() != CHG_OFF_FULL_BAT ) {
writel(0x00080001, USB_USBCMD);
mdelay(10);
htcleo_set_charger(CHG_OFF_FULL_BAT);
}
// and turn led solid green
if (htcleo_usb_online() && (htcleo_notif_led_mode != 1))
thread_resume(thread_create("htcleo_notif_led_set_mode_1",
&htcleo_notif_led_set_mode,
(void *)1,
HIGH_PRIORITY,
DEFAULT_STACK_SIZE));
} else {
// exit while if we don't have a timeout
break;
}
}
} else {
// Set charger state to CHG_OFF
if (htcleo_charger_state() != CHG_OFF ) {
writel(0x00080001, USB_USBCMD);
mdelay(10);
htcleo_set_charger(CHG_OFF);
}
// and turn off led
if (htcleo_notif_led_mode != 0)
thread_resume(thread_create("htcleo_notif_led_set_off",
&htcleo_notif_led_set_mode,
(void *)0,
HIGH_PRIORITY,
DEFAULT_STACK_SIZE));
}
// While in loop keep tracking if POWER button is pressed
// in order to (re)boot the device
for (int i=0; i<6; i++) {
if(keys_get_state(KEY_POWER)!=0) {
target_reboot(0);
return;//:)
}
mdelay(96);//total delay ~500ms per loop
}
// And check if timeout exceeded in order to reboot
if (timeout && (current_time() - start_time >= timeout))
target_reboot(0);
} while ( (usb_cable_connected) /* && current >= 0) */
||(timeout) ); // If we have a timeout this while-loop never breaks if we don't reboot.
// Double check voltage
mdelay(10);
voltage = ds2746_voltage(DS2746_I2C_SLAVE_ADDR);
if (voltage < DS2746_SAFE_CHG_VOLTAGE) {
// If battery is not full then
// EITHER the cable is unplugged
// OR the double check of voltage gave us
// a value less than the safe voltage.
// Set charger state to CHG_OFF
writel(0x00080001, USB_USBCMD);
mdelay(10);
htcleo_set_charger(CHG_OFF);
} else {
// If battery is full
// set charger state to CHG_OFF_FULL_BAT
writel(0x00080001, USB_USBCMD);
mdelay(10);
htcleo_set_charger(CHG_OFF_FULL_BAT);
// and turn led solid green
if (htcleo_usb_online() && (htcleo_notif_led_mode != 1))
thread_resume(thread_create("htcleo_notif_led_set_mode_1",
&htcleo_notif_led_set_mode,
(void *)1,
HIGH_PRIORITY,
DEFAULT_STACK_SIZE));
// While usb cable is connected
// keep tracking if POWER button is pressed OR timeout exceeded
// in order to (re)boot the device
while (htcleo_usb_online()) {
if(keys_get_state(KEY_POWER)!=0)
target_reboot(0);
/* if (timeout && (current_time() - start_time >= timeout))
break; */
}
}
// If we've set a timeout and reached it, reboot the device
/* if (timeout && (current_time() - start_time >= timeout))
target_reboot(0); */
// Shutdown the device
enter_critical_section();
platform_exit();
msm_proc_comm(PCOM_POWER_DOWN, 0, 0);
for (;;) ;
}
Any suggestions or observations are welcomed!
This is open for everyone to use or contribute. Source is available at https://github.com/n0d3/HD2_Alarm_Clock
If you have to ask for an apk to test, then you may download this example's apk from here.But don't consider this as an application release thread.
Bazinga
Should I say first or something? Anyway, testing with ~.7 clk now
Thank you!
THANKS KOKOTAS to make it possible also if it is an experiment..
almost you try if it's possible to use it in our beloved hd2
now i try it,and test this version..
however there is an app for samsung phone developer from chainfire team nomoarpowah that use offline charging mode for alarm..
maybe you can check that app to see if can use something
i hope that OUR WONDERFUL DEVELOPER can do another miracle..
I think since Android is between us, make a wake up alarm is really hard to do. Because we need a sub level software such as a boot loader, that listen the internal clock to turn on the device when established. I hope that you will win this challenge bro
All the best !
Although I think this Will be difficult...
zicoxx said:
THANKS KOKOTAS to make it possible also if it is an experiment..
almost you try if it's possible to use it in our beloved hd2
now i try it,and test this version..
however there is an app for samsung phone developer from chainfire team nomoarpowah that use offline charging mode for alarm..
maybe you can check that app to see if can use something
i hope that OUR WONDERFUL DEVELOPER can do another miracle..
Click to expand...
Click to collapse
Chainfire use the charging deamon to include his project. Because we doesnt see source which are availible for the HD2 we couldnt build something like this. Another point would be that the device comes original by windows Mobile so the process completly differs like bootloader/ init by spl/ availible functions !
If you Test chainfire app and read the thread you readout that most of them completly new written coded.
Alarm is integrated into new charging deamon so it doesnt fire device to boot up normal android ...
See it like another very small System work completly alone if device is off (charging)
Sent from my GT-I9300 using xda app-developers app
tb-killa said:
Chainfire use the charging deamon to include his project. Because we doesnt see source which are availible for the HD2 we couldnt build something like this. Another point would be that the device comes original by windows Mobile so the process completly differs like bootloader/ init by spl/ availible functions !
If you Test chainfire app and read the thread you readout that most of them completly new written coded.
Alarm is integrated into new charging deamon so it doesnt fire device to boot up normal android ...
See it like another very small System work completly alone if device is off (charging)
Sent from my GT-I9300 using xda app-developers app
Click to expand...
Click to collapse
If you look closely, It should work already and NOT require any of chainfire's work. cLK is open source, Linux is open source, Android is open source (atleast the part related to this). The only issue you might think of is that the core will be in wfi state instead of pc, unless kokotas has fixed pc in clk.
kokotas said:
Code:
unsigned code = simple_strtoul(cmd + 1, 0, 16) & 0xff000000;
Click to expand...
Click to collapse
Don't you think it should be
Code:
unsigned code = simple_strtoul(cmd + 1, 0, 16) & 0x00FFFFFF;
That's a good point.
I think booting into android to have a ring might be an issue in some cases
(bootloop, long time to boot android itself)
Using a recovery mode to quickly boot into and initiate an alarm that would be more reliable.
... at least I think
nerveless, good job and keep up the good work
Very nice work, seems like more and more people are learning to dev.
Rick_1995 said:
If you look closely, It should work already and NOT require any of chainfire's work. cLK is open source, Linux is open source, Android is open source (atleast the part related to this). The only issue you might think of is that the core will be in wfi state instead of pc, unless kokotas has fixed pc in clk.
Click to expand...
Click to collapse
I think we doesnt have sources of charging deamon for the HD2 right?
If we checked different threads we could read that htc doesnt public sources for Desire, others!
I agree that C(LK) could also do the Same job!
Sent from my GT-I9300 using xda app-developers app
tb-killa said:
I think we doesnt have sources of charging deamon for the HD2 right?
If we checked different threads we could read that htc doesnt public sources for Desire, others!
I agree that C(LK) could also do the Same job!
Sent from my GT-I9300 using xda app-developers app
Click to expand...
Click to collapse
code for charging daemon is not needed....
@kokotas, Why aren't you entering WFI state ?
You should do something like this:
Create a suspend thread and ensure there is no other thread with a higher (or the same) priority.
Inside the thread handle, there should be an infinite loop with something like this:
Code:
int suspend_task(void *args) {
int timeout_ms = (uint32_t) args;
htcleo_panel_bkl_pwr(0);
while( ! (key_pressed(KEY_POWER) && (timeout_ms <= 0)) ) {
if(usb_is_connected())
charge_device();
else
arch_idle(); // WFI
timeout_ms -= 10;
}
reboot();
return 0;
}
#define MARK_ALARM_TAG 0x53000000
void board_init(void) {
.........
uint32_t MinutesToSuspend = target_check_reboot_mode();
if((MinutesToSuspend & 0xFF000000) == MARK_ALARM_TAG) {
MinutesToSuspend &= 0x00FFFFFF;
if (MinutesToSuspend > 3)
MinutesToSuspend -= 2;
thread_create("suspend", suspend_task, (void *) (MinutesToSuspend * 60000) , HIGHEST_PRIORITY, DEFAULT_STACK_SIZE)
}
.........
}
Rick_1995 said:
@kokotas, Why aren't you entering WFI state ?
Click to expand...
Click to collapse
Honestly, never thought of Wait For Interrupt state
I'll rewrite the code based on your example and I'm thinking of creating a new branch in git in order to upload the complete source of latest cLK.
Regards!
kokotas said:
Honestly, never thought of Wait For Interrupt state
I'll rewrite the code based on your example and I'm thinking of creating a new branch in git in order to upload the complete source of latest cLK.
Regards!
Click to expand...
Click to collapse
Thanks, was wanting to update too. Just remember to create a new branch instead of an entirely new repository.
Regards
FYI.
Kernel patch arch\arm\mach-msm\pm.c in the first post has already added into my git.
It was included in my latest ICS kernel r3.6.
https://github.com/tytung/android_k...mmit/23357b2a9d64a076f1b9ac664dae209748fd5ece
tytung said:
FYI.
Kernel patch arch\arm\mach-msm\pm.c in the first post has already added into my git.
It was included in my latest ICS kernel r3.6.
https://github.com/tytung/android_k...mmit/23357b2a9d64a076f1b9ac664dae209748fd5ece
Click to expand...
Click to collapse
Thank you tytung:good:
I changed the relevant source in the application (also updated git repo) and tested successfully.
This also gave me the chance to try something else. Since it makes "oem-" prefix available to be used for other purposes, I've written another application which uses that prefix in reboot_reason for rebooting directly to any extra boot partition, with no need to press any buttons during boot-up.
Will post more info in a separate thread.
EDIT1:
Link
EDIT2:
Rick_1995 said:
Thanks, was wanting to update too. Just remember to create a new branch instead of an entirely new repository.
Regards
Click to expand...
Click to collapse
Just created new branch here.
Regards!
Thank you for your great work.I am trying to make offmode alarm work in clk 1.5.1.5 and nand rom nexushd2 v2.8
After i press set alarm device reboots but then it gives message "error:boot selection not found.an irrecoverable error found" and it boot in clk menu and stays there.I have boot,sboot partition and i select from default kernel the boot partition
clio94 said:
Thank you for your great work.I am trying to make offmode alarm work in clk 1.5.1.5 and nand rom nexushd2 v2.8
After i press set alarm device reboots but then it gives message "error:boot selection not found.an irrecoverable error found" and it boot in clk menu and stays there.I have boot,sboot partition and i select from default kernel the boot partition
Click to expand...
Click to collapse
Hi clio94,
Did you download the SysAlarm2.apk or you're still using the first one (SysAlarm.apk)?
Now that I think of it, I should remove the first one cause it will not work as expected with the last cLK.
Regards!
I tried the first version.The second version work ok.Thank you
clio94 said:
I tried the first version.The second version work ok.Thank you
Click to expand...
Click to collapse
Have you try in nand rom or nativesd ROM?
Thanks!!
Inviato dal mio multiboot HD2
Hello alltogether,
I digged into the Lollipop code to look for a solution to restore the old Kitkat silent mode in Lollipop with Xposed.
I got a working prototype now but would like to add the silentmode icon back to the statusbar.
Unfortunately it got removed in Lollipop so I have to port it forward from an older ROM.
To do that I need to hook into the PhoneStatusBarPolicy class, which for some reason fails.
This is my code:
Code:
private static final String CLASS_PHONE_STATUSBAR_POLICY = "com.android.systemui.statusbar.phone.PhoneStatusBarPolicy$1";
public void handleLoadPackage(final LoadPackageParam lpparam) throws Throwable {
if (lpparam.packageName != "android")
return;
final Class<?> classStatusbarPolicy = XposedHelpers.findClass(CLASS_PHONE_STATUSBAR_POLICY, lpparam.classLoader);
XposedHelpers.findAndHookMethod(classStatusbarPolicy, "updateVolumeZen",
new XC_MethodReplacement() {
...
});
}
}
But for some reason it fails:
Code:
Caused by: java.lang.ClassNotFoundException: Didn't find class "com.android.systemui.statusbar.phone.PhoneStatusBarPolicy" on path: DexPathList[[zip file "/system/framework/services.jar", zip file "/system/framework/ethernet-service.jar", zip file "/system/framework/wifi-service.jar"],nativeLibraryDirectories=[/vendor/lib, /system/lib]]
Does anyone have an idea?
Thanks!
You should change lpparam.packageName != "android"
to
lpparam.packageName.equals("android")
Why android? This class is within com.android.systemui package.
C3C076 said:
Why android? This class is within com.android.systemui package.
Click to expand...
Click to collapse
Ah I guess I misread rovos post about the new API with the dummy android package.
In detail, this means: If you want to hook a system service like PackageManagerService, you can no longer do that in initZygote(). Instead, move your code to handleLoadPackage() and check for dummy package "android". Make sure you use lpparam.classLoaders when looking for classes and hooking methods. This way has worked in older Android versions as well, so you don't lose backwards-compatiblity.
Click to expand...
Click to collapse
After reading it again this just applies to system services. And based on some code I saw at your Gravitybox repo it doesn't even seem to apply to all system services as you are still hooking a couple during initZygote
Xposed is new to me, but it's an amazing toolset!
So hooking works fine now, unfortunately it just got a bit ugly as the StatusBarManager which I'd like to use for the icons can't get imported. I guess I'll have to use some reflection to get into the class hehe.