[ROM][JB][4.3][2013-12-29] CyanogenMod 10.2


"long press back key to close currets app?"
That already present in every CM rom under development options, isn't it?
 
Which operator name does it show in MIUI?

Yup its shows correct in MIUI amd other CM builds,operator name is Airtel..!

@RobinHood00 Well review wise its a great rom expect the issues that i have said and it will take time to make all things to work..!
Since i'm using skype all the time and the mic won't work in this rom i switched back to miui..!
Once again a great work by M1cha..!
 
Yup its shows correct in MIUI amd other CM builds,operator name is Airtel..!

@RobinHood00 Well review wise its a great rom expect the issues that i have said and it will take time to make all things to work..!
Since i'm using skype all the time and the mic won't work in this rom i switched back to miui..!
Once again a great work by M1cha..!
did you try Skype mod version on xda? it might work

Inviato dal mio MI 2S con Tapatalk 4
 
can you add some features like:
1. "WCDMA/3G only" on network selection;
2. long press back key to close currets app?

it'd be great.
Sry, but as already said I don't change any CM code because this is just a port and not a custom rom.
 
  • Like
Reactions: type-R
@M1cha: Hello M1cha, how is it going? Are you finding any major problem?
Thanks again for your work: I really appreciate it!
 
  • Like
Reactions: M1cha
Beside the camera (it will work when it will work... :) ), the most annoying problem, for me, in your last build is the in-call audio volume, which is always too loud.
If you think fixing the camera will take a longer work (I can live without it for another while), and if I'm not asking too much, would it be possible to make an "intermediate" build with (possibly) the in-call audio fixed?
I'm a developer too and I know that the source-tree, at times, can be very messed-up until the final build, so if this is too much work: just forget it, I'll wait.
 
your last point is true. I've messed up so much due to several kernel switches etc and I'm just happy to have any working rom where I can test the new kernel.
Once the kernel is finished I can create the device tree from scratch and compile another build.

We'll see which bugs it will have then.
 
Hi M1cha, testing your rom in dual boot with wiui on MI2, really really great work!
Smooth and almost bugfree!
an opinion only about the battery, noticed results are really far away than, for example, latest wiui roms, expecially in standby mode, lost about 10% battery in one night against 3-4% of wiui...still go on testing anyway and waiting for the camera to work :)
 
an opinion only about the battery, noticed results are really far away than, for example, latest wiui roms, expecially in standby mode, lost about 10% battery in one night against 3-4% of wiui...still go on testing anyway and waiting for the camera to work :)
This drain is because of the kernel problems I guess?
 
I worked the last 3 days on camera and now have a idea about the problems.
The core problem is that the very old camera lib doesn't work with the new kernel and downgrading kernel parts is very crazy.
I'm probably wrong, but, if you can identify the camera chips (front and rear) using the opensourced xiaomi kernel, did you already tried to see if there is already written code to use those chips with the new kernel?
Maybe it saves you some burden.
 
I'm probably wrong, but, if you can identify the camera chips (front and rear) using the opensourced xiaomi kernel, did you already tried to see if there is already written code to use those chips with the new kernel?
Maybe it saves you some burden.
very good idea. If he see in the sony source code he could try, at least i think.
 
Guys, M1cha knows what camera models are used. He just said that the older version of drivers required are malfunctioning with the newer kernel.

Sent from my MI 2S using Tapatalk 4
 
I try to give a easy explanation:
qcom is stupid :p

The wrote wrappers on both sides(kernel and android-HAL) and put the real camera drivers into liboemcamera.so.
Since this library basically is a exported closed source driver it heavily depends on the kernel.
That means that this lib can't communicate with newer kernels that's why I have to downgrade all the parts this library needs.
 
I try to give a easy explanation:
qcom is stupid :p

The wrote wrappers on both sides(kernel and android-HAL) and put the real camera drivers into liboemcamera.so.
Since this library basically is a exported closed source driver it heavily depends on the kernel.
That means that this lib can't communicate with newer kernels that's why I have to downgrade all the parts this library needs.

That's why one of the founders of AOSP write an open letter against qualcomm and his architecture difficulting the progress of Android platform, but is aways great to see your progress despite Xiaomi's and Qualcomm limitations!
 
I try to give a easy explanation:
qcom is stupid :p

The wrote wrappers on both sides(kernel and android-HAL) and put the real camera drivers into liboemcamera.so.
Since this library basically is a exported closed source driver it heavily depends on the kernel.
That means that this lib can't communicate with newer kernels that's why I have to downgrade all the parts this library needs.

Would it be possible to rewrite the driver from scratch using the CodeAurora source code? It also seems stupid they're practically 3 shims needed to interact with the camera in Android JB and up.
 
As far as I know codeaurora doesn't provide the source for this lib

And the lib is that big that it would take much months to do this.
 
Last edited:
@M1cha: Of course I don't know how things are in reality, so please forgive me if I say something stupid...

Instead of downgrading the kernel, wouldn't it be better to add a software layer to "translate" the calls to the "old" library?
Maybe in this phase it is easier/shorter to downgrade the relevant kernel parts, but in the long term?
(of course, in the long term we all hope that qcom will upgrade the library / release the sources, but I think we have to live with what we have, no?)
 
I took a look at the oppo find5 sources.(they have same SoC but much more other differences than mi(2))
They are stuck with 4.1 libs, too and they dowgraded drivers/media and added compatibility-code(what u wanted todo, just for one part only) to ion driver.

I'll fix device-tree and recompile cm10.2 today and hopefully camera will work then(it already works with mako-kernel+ivans rom).
 
I took a look at the oppo find5 sources.(they have same SoC but much more other differences than mi(2))
They are stuck with 4.1 libs, too and they dowgraded drivers/media and added compatibility-code(what u wanted todo, just for one part only) to ion driver.

I'll fix device-tree and recompile cm10.2 today and hopefully camera will work then(it already works with mako-kernel+ivans rom).

Any luck?
 
I know that Mako is code name for nexus 4, i have that phone too :) but i asked because of this: I'll fix device-tree and recompile cm10.2 today and hopefully camera will work then(it already works with mako-kernel+ivans rom).
 
I know that Mako is code name for nexus 4, i have that phone too :) but i asked because of this: I'll fix device-tree and recompile cm10.2 today and hopefully camera will work then(it already works with mako-kernel+ivans rom).

I think this is what it means and that's also the reason why this project is so fantastic!
(This project is actually the reason I bought the M2S, still waiting on it though.)

Well, CM10.2 is nice but that's not all this is about.
I've build this with the aim to have max compatibility with Nexus 4 sources and that really was a success.
I'm using device repository, kernel source and 90% of the proprietaries from Nexus 4.

What does that mean to the Users?
You have maximum stability, security and speed and you'll get the latest Android versions at least as long as Google supports the Nexus 4.

What does that mean to the Developers?
Google did a very good job with the code style of the device. It's clean and easy to understand.
The changes that we need for MI2 are that minimal that we should be able to port any Nexus 4 ROM or kernel within hours.
 
  • Like
Reactions: M1cha

Similar threads

Replies
254
Views
108K
Replies
93
Views
79K
Replies
142
Views
72K
Replies
251
Views
112K