Compiling CM9 (and maybe CM10) for Blade

[Guest shmizan]

hmm. they actually have a point since almost nobody will use it, but for the few of us that will, it sucks. so one choice is to send the 1 every time we flash a new build via adb, but we can also make our own patch to revert the removal of the feature.

[Guest shezar]

hmm. they actually have a point since almost nobody will use it, but for the few of us that will, it sucks. so one choice is to send the 1 every time we flash a new build via adb, but we can also make our own patch to revert the removal of the feature.

Since the prop is on /data you won't need to send it on every flash.

[Guest targetbsp]

as far as things not being set on reboot, i think there may be a bug or two in the properties system, or its different to cm7 as i've found a couple of things that don't work such as debug.sf.nobootanimation=1 in build.prop, with cm9 you have to echo 1 > /data/property/persist.sys.nobootanimation to get it to work.

Glad we have a solution to that option being removed. Having no boot animation makes a hot reboot about 3 times faster!

[Guest shmizan]

stupid keyboard lag :angry2:

05-19 21:06:33.859 I/ActivityManager( 189): Process com.android.inputmethod.latin (pid 356) has died.

05-19 21:06:33.859 W/ActivityManager( 189): Scheduling restart of crashed service com.android.inputmethod.latin/.LatinIME in 5000ms

[Guest shezar]

stupid keyboard lag :angry2:

05-19 21:06:33.859 I/ActivityManager( 189): Process com.android.inputmethod.latin (pid 356) has died.

05-19 21:06:33.859 W/ActivityManager( 189): Scheduling restart of crashed service com.android.inputmethod.latin/.LatinIME in 5000ms

Well I've set my keyboard to hungarian/hebrew and gave it a try, mine didn't die for some reason so unfortunately I can't do much about this. Is there something relevant about the crash in your logcat besides these rows?

Blackscreen fix got merged. :) http://review.cyanogenmod.com/#/c/15946/

Edited May 20, 2012 by shezar

[Guest shmizan]

yeah lots of relevant stuff. unfortunately this keyboard crash is not unique to the Blade. it's on other ICS devices too (according to Tom) and since there's no RC I can't send bug reports about this to CM team.

edit: by the way, the way to reproduce it is to type random letters in Hebrew and let auto correct do its thing. then it happens

Edited May 20, 2012 by shmizan

[Guest shezar]

yeah lots of relevant stuff. unfortunately this keyboard crash is not unique to the Blade. it's on other ICS devices too (according to Tom) and since there's no RC I can't send bug reports about this to CM team.

edit: by the way, the way to reproduce it is to type random letters in Hebrew and let auto correct do its thing. then it happens

Thanks for the reproducing info, this is really quite annoying.

I'll try to get to the end of it (seems like a segmentation fault) but until then just disable autocorrect if it is not essential. (Actually it's most likely I'll only be able to try :) )

Edited May 20, 2012 by shezar

[Guest shmizan]

thanks.

I like the twice-space-equals-dot thing so I just replaced the dict files for now (with the empty one from the raw folder)

log is here if you're interested

[Guest shezar]

thanks.

I like the twice-space-equals-dot thing so I just replaced the dict files for now (with the empty one from the raw folder)

log is here if you're interested

Well this needs time, the lib is a bit hard to comprehend. :)

Anyways if someone wants to have a look: LatinIME/native/src/correction.cpp, Correction::processCharAndCalcState() is the last function called which has it's name output to the log (I'm not sure yet about the 2 "nameless" calls after that...)

I'll investigate it further if I'll have more time (and it doesn't get fixed until then).

Oh and I'm not sure but it may be that there's an error in the .dict files for Hebrew language.

Edited May 20, 2012 by shezar

[Guest sej7278]

one of the reverts has been replaced, looks like now you need:

patch3 of this: http://review.cyanog....com/#/c/16203/

patch4 of this: http://review.cyanog....com/#/c/16028/

and add this line to device/zte/blade/BoardConfig.mk

BOARD_ADRENO_DECIDE_TEXTURE_TARGET := true[/CODE]

actually both of these seem [s]broken[/s] totally fscked up, they won't even compile, even with workarounds.

Edited May 20, 2012 by sej7278

[Guest shezar]

Weird because the code is fine apart from the left-in QCOM define

[Guest C3C0]

I got it fixed. It's in my github

Edited May 20, 2012 by C3C0

[Guest shezar]

I got it fixed. It's in my github

I know I saw the comment but I don't understand the error itself and that's my problem...

By the way if you put in an extra function call, why not simply remove the definition without parameter? The default one should cover that case, too.

Edited May 20, 2012 by shezar

[Guest C3C0]

By the way if you put in an extra function call, why not simply remove the definition without parameter? The default one should cover that case, too.

No. You'll end up with missing prototype. It must be defined in header file.

Anyway, I don't uderstand the error too. It should work.

By the way, it's not the compiler that has problem. It's fine with that.

But linker is... For unknown reason (to me)...

Edited May 20, 2012 by C3C0

[Guest shezar]

No. You'll end up with missing prototype. It must be defined in header file.

No I meant to leave the function with the default parameter there. With prototype definition and all of course, I wouldn't advise a mindless removal from one file.

[Guest sej7278]

why are they trying to call updateTexImage() with parameters, when it doesn't take any.....?

http://developer.android.com/reference/android/graphics/SurfaceTexture.html#updateTexImage%28%29

no offence C3C0 but your fix is a bit hacky, i think Arne/Steve. need to go back and rethink the patches.

[Guest shezar]

Simon it takes an argument in CM9 if compiled for an Adreno:

http://review.cyanog...urfaceTexture.h

Well at least it will take an argument if it gets fixed and merged...

Edited May 20, 2012 by shezar

[Guest sej7278]

Simon it takes an argument in CM9 if compiled for an Adreno:

http://review.cyanog...urfaceTexture.h

Well at least it will take an argument if it gets fixed and merged...

but it doesn't though does it - if they overloaded it, it could, but they're not doing that, so it can't. they're calling it without parameters outside the ifdef and with inside, now unless i'm not seeing another ifdef where they overload it, they're talking crap.

i think that's what C3C0 is trying to prevent happening at line 853 of his github.

ah daniel buga is onto the same thing, even patch5 is wrong.

Edited May 20, 2012 by sej7278

[Guest shezar]

but it doesn't though does it - if they overloaded it, it could, but they're not doing that, so it can't. they're calling it without parameters outside the ifdef and with inside, now unless i'm not seeing another ifdef where they overload it, they're talking crap.

Did you notice the ifNdef there? :)

Anyways there's a new patchset and I made two additional recommendations there to simply remove that argument.

Edited May 20, 2012 by shezar

[Guest sej7278]

Did you notice the ifNdef there? :)

Anyways there's a new patchset and I made two additional recommendations there to simply remove that argument.

seems to finally work with patch3 and patch5, but needs some tidying still.

bit annoying that every device is now going to need to change their BoardConfig.mk

[Guest shezar]

seems to finally work with patch3 and patch5, but needs some tidying still.

bit annoying that every device is now going to need to change their BoardConfig.mk

Irritating but we have to live with that... One row won't be so hard to insert actually. :) Actually the numer of ifdefs needed is disturbing as it will make debugging/modifying that code an insanely complex task (yet it doesn't deserve a //Magic, do not touch comment).

I think they should count how much devices with the QCOM_HARDWARE macro need this patch, how much of them doesn't need it and include additional macros for the minority of devices... But this decision is out of my hands and we have a working solution now.

[Guest sej7278]

Irritating but we have to live with that... One row won't be so hard to insert actually. :) Actually the numer of ifdefs needed is disturbing as it will make debugging/modifying that code an insanely complex task (yet it doesn't deserve a //Magic, do not touch comment).

I think they should count how much devices with the QCOM_HARDWARE macro need this patch, how much of them doesn't need it and include additional macros for the minority of devices... But this decision is out of my hands and we have a working solution now.

regarding the one line, yes its simple but will still take days to get merged in gerrit.

as far as the ifdefs go, yes its messy and by the looks of the comments it seems only one samsung device running bleeding edge drivers is actually benefiting from this.

[Guest shmizan]

and unfortunately it's Steve Kondik's one? argh this is so useless. I'm halting all my builds until this is sorted and it seems they're taking their time!

[Guest sej7278]

and unfortunately it's Steve Kondik's one? argh this is so useless. I'm halting all my builds until this is sorted and it seems they're taking their time!

the single device that benefits? yeah its steve's, that's what you get when its a favoured device of cyanogenmod and google.... its shiz like this that makes you want to switch to another mod, but aokp are even worse about non-samsung/google devices apparently, they really are aosp-supported devices only.

if you use patch5 and patch3 it compiles ok (you must delete out/) even if it is a bit hacky/pointless.

also tilal6991 added the BoardConfig.mk line to his existing http://review.cyanogenmod.com/#/c/16106/

[Guest targetbsp]

Mine compiled fine without deleting out. :)

Also, Sej, your signature is really useful. Whenever I compile a rom I just take whatever is pending for Blade and whatever is in your sig and all is good. :D