yashsingh1/xdaforums huggingface dataset:
[Nexus 4 Android Development] SkyBeam2048:
The issue is that Google created two versions of Android 4.3 for the Nexus 4:

- AOSP code (JSS* build)

- Factory Images (JWR* build)

They both seem to be incomatible in terms of some graphics routines and as well regarding the "delayed notification" fix and related settings in wifi driver configuration. It looks like most experts believe that AOSP JSS code is newer and more correct than JWR factory images which have offloading features disabled and do not fix delayed notifications for some of the users. Unfortunately kernel maintainers would have to support both versions with independent kernel builds which is a lot of additional effort. Also in the future custom patches to either branch might have to be applied. Fixes and work-arounds will have to be applied to two kernel branches etc.

To say it with the words of the beloved Duke: What a mess!

Due to this mess I actually refused to upgrade to 4.3 yet and I am waiting for official CM 10.2 builds right now. The reason is simply that I would like to have an automatic upgrade mechanism and clear release schedule. I am sure this kernel will support CM 10.2 as soon as it's out officially. Up to then I am neither bothering with JSS or JWR custom builds as it really appears to be total mess.

Shame on you Google for creating such issues during 4.3 release (along with other issues like missing source for new Nexus 7 v2). I would really have hoped for Google to release a fixed JSS-based OTA update and factory images or alternatively update AOSP code to match JWR factory images by providing the reason for reverted offloading switches.

Right now the situation is really awful. Perhaps the only one realizing this at Googla was JBQ who took the consequences and left the AOSP project.

Again: Shame on you Google!
[Nexus 4 Android Development] azrash:
Same reasons here, I am still sticking to CM10.1 for now. And s2w2 is still being worked on for 4.3 IIRC

Flowed from my Nexus⁴ using Tapatalk 4 Beta
[Nexus 4 Android Development] thracemerin:
JSS15J is really only supposed to be for the Nexus 7 (2013), all other Nexus devices are supposed to use AOSP builds based on JWR66V which is also in AOSP, just in a different 4.3 release branch, this has been explained by Google, of course the people on XDA prefer to ignore that and build their ROMs for N4 based on JSS15J and then complain that there are incompatibilities and other issues.

While I'd like to support both, I've sort of decided to let the dust settle a bit more before I decide the best course of action for the future. There are some commits in the dev tree for JSS15J that are aimed at fixing the deadlocks that appear to be causing most of the issues for that version, if it does indeed get fixed then I think all custom ROMs will end up based on JSS15J, if that ultimately doesn't fix the problem many of them may revert back to JWR66V, once this is decided better I will make a decision on how to proceed. In the mean time I am using unofficial CM10.2 which is based on JSS15J so it's easier for me to test and push builds for that firmware rather than having to swap back and forth repeatedly to ensure there aren't issues, I realize this means that some people can't use this kernel, but at this point it's unavoidable.
[Nexus 4 Android Development] SkyBeam2048:
Also I seem to have missed this explanation. Perhaps due to the fact that I am mainly follwing XDA discussions where people tend to ignore this fact as you said.

So actually for the Nexus 4 builds should be based on JWR66V.

It looks like there is an official CM 10.2 nightly out. I did not install it yet and I won't until there is an _m+ kernel available for it. I guess CM 10.2 is also based on (actually wrong as you claim) JSS15J code.
[Nexus 4 Android Development] thracemerin:
I'm running this kernel on CM10.2 at the moment without issue, it is based on JSS15J but they implemented some of the upstream fixes for the deatlock issues and I haven't had any noticeable lockups unlike when i was on a purer AOSP version, so you should be good to use that.
[Nexus 4 Android Development] veyka:
Using this with the now officially cm 10.2, no issues what so ever, running great, and mpdesison seems to be working well, no battery issues, plus the hsci stuff is all good!
[Nexus 4 Android Development] nickwarn:
Using this kernel on PA 4.3 and its just tiptop, damn its smooth! Sure I have to force Gpu rendering and check the disable HW overlay option to avoid graphical issues but its no problem. Have to say thank you OP, I just love the smoothness.
[Nexus 4 Android Development] logo20heli:
I'm running the 4.2.2 version of m+. Before I move to the official CM 10.2 nightly and this version of m+, I wanted to know if it supports CIFS like the 4.2.2 version does. Thanks in advance.
[Nexus 4 Android Development] SkyBeam2048:
I would like to do the same. However there is one question I couldn't clarify by reading the documentation.

I am used to run 4.2.2 with _m+ and hotplug. As far as I know this kernel does not yet include CPU hotplugging driver and uses mpdecision instead. Although I am using hotplugging configuration to limit the number of online CPUs to 2 rather than using 4 for battery improvement. I personally even run limited to 810MHz max with maximum 2 CPUs online without seeing any negetive impact on performance on my day-by-day usage scenarion.

Is there any possibility to limit the maximum number of CPUs using mpdecision?

As far as I know the frequency limit should work with mpdecision too, but what about hotplugging?
[Nexus 4 Android Development] thracemerin:
Unfortunately you can't limit the number of cores or the maximum frequency while using mpdecision, I'm thinking about auto-hotplug and I have an internal testing version with it enabled, but it's not ready for prime time yet. The trade off here is, mpdecision is smoother than auto-hotplug, but it has fewer customization options, so we'll see.
[Nexus 4 Android Development] SkyBeam2048:
Thanks for the reply. I wasn't fully sure whether mpdecision also replaces governor or overrides its settings (I am using ondemand). I know that many people seem to be very concerned about smoothness. Personally I am more concerned about battery lifetime. Especially as I am usually not able to see any difference in smoothness among governors or boost settings etc. I am also sceptical whether CPU boost time on touch really adds smoothness as frequency change (ramp-up) also causes the CPU to "stutter" as it cannot perform a frequency switch in no time, which actually means exactly this boost leads to some "frozen state" while changing frequency.

Don't get me wrong; I do actually care about smooth scrolling too. When I browse a list I hate it to stutter irregularly. It's lessa annoying if just the framerate is low than when it just stucks for some ms every now and then. But smooth list browsing is more a GPU thing than CPU I believe.

Anyway as said I am used to limit my Nexus 4 to 2 Cores@810MHz and for my personal experience it's smooth as butter (using Go Launcher usually) and all application including some of the games I play are smooth too. So I personally really think Google did a mistake designing a smartPHONE to include a powerful 4-core CPU. It's nice on paper and very nice for benchmarks but vastly useless in day-by-day usage for most people.

Sure there are people most concerned about benchmark results, even more than usability in real-life scenarios. The good thing about Android is that it supports both use-cases by tweaking governors. As mpdecision seems to be limited in terms of configuration (and also no sources are available AFAIK) I would of course love to see get hotplugging added to Android 4.3 kernels.
[Nexus 4 Android Development] miguepereira77:
Then, the real question here in all that mess is why Google created a different build for flo instead of using JWR as well, is it because, as I read, JWR didn't boot on the new N7? and they have to made a "fast fixed build"?

Enviado desde mi Nexus 4 usando Tapatalk 4
[Nexus 4 Android Development] Kocai:
Edit: Tapatalk derp. Posted in the wrong thread. Sorry.

Sent from my Nexus⁴
[Nexus 4 Android Development] opus1one1:
Pretty sure Faux sound headphone boost isn't work, I'm also pretty sure this is a 4.3 wide issue in all kernels with Faux sound.
[Nexus 4 Android Development] logo20heli:
Sorry if this is the wrong thread for this question; if it is, please let me know. I am using m+ and think its a great kernel. Thanks to both thracemerin and motley for their hard work on the kernel.

I went ahead and tried CM 10.2 with m+ and found that it doesn't support CIFS like the 4.2.2 version does. Specifically, I was hoping that the issue described in this thread was fixed: Fix for empty app-mounted directories (CifsManager, etc.) in Android 4.2

I use the Cryptonite Android app to mount TrueCrypt volumes and without the patch described in that thread, the mounted FUSE volume doesn't appear to other applications. In that thread, it appears like the patches were merged into CM 10.1 (see post #39). I think there are two patch reviews and they are here and here.

I was assuming that since they were merged into CM 10.1, that those changes would be in CM 10.2, but I'm not sure they are from my testing. Is it possible that they weren't included in CM 10.2? Also, would it be possible to add these changes into m+ if they aren't in 10.2? Or does it make more sense to get them into CM 10.2 kernel first? TIA
[Nexus 4 Android Development] passlogin:
FauxSpeaker support?

---------- Post added at 03:07 AM ---------- Previous post was at 03:05 AM ----------

Nope, running matrix kernel with both fauxsound and speaker working fine.
[Nexus 4 Android Development] veyka:
CM has seen a lot of CAF merges in the past say or so, krait retention stuff and more, do we have most of these patches?

Also looks like they are finally going to merge a gamma interface! Woo
[Nexus 4 Android Development] thracemerin:
Most of the Krait stuff is ROM side not kernel side, but the ones that are kernel side should be in right now :)

I'm amused by the whole rant by pulser_g2 about how Arcee was singlehandedly removing all the cool features from CM, when the evidence suggests the opposite is true.
[Nexus 4 Android Development] veyka:
Good to know, thanks.

Pulser is a good chap, I think he just got annoyed by stuff being removed before it was reimplemented in a cleaner way.

Nightlys came up pretty quickly this time, it seems they decided not to wait as long for things to calm down starting them, good for those without patience (like me) not so good if you are not willing to deal with the mess that being in flux brings.
[Nexus 4 Android Development] thracemerin:
I don't think his rant was wrong, I think he jumped the gun a little without the appropriate information and as I'm sure you're aware when someone like pulser says something like that everyone gets in a huge knot and G+, Twitter, FB, etc... blow up about it.
[Nexus 4 Android Development] veyka:
Oh yes, I just ignore all that guff, people will always find something to get annoyed about.

I hope in the end we do just end up with a sane way to have device specific tunables in logical places, the old settings menu was hell to find things in.
[Nexus 4 Android Development] thracemerin:
Looks like CM gamma control got merged, it's based on Faux123s interface but I don't know if it's compatible with the one that's in this kernel or not, if not I'll make it work.

I'm also working on getting a test version without mpdecision working for comparison.
[Nexus 4 Android Development] Kearkan:
Hey thracemerin

Firstly, Absolutely love this kernel. Running it on PA 3.94 and besides the odd freeze bug, its great.

Firstly this is NOT a request for an ETA or anything like that. Just wondering about your intentions for the future of this kernel.

PA has recently moved to the JW builds (and I think someone said there is a JW ota coming out). I only found this out after investigating why paOTA suddenly stopped working. But that's beside the point.

You had said before you were waiting for the dust to settle on the whole JW/JS thing, so with it seeming that JW is starting to come to our ROMS (I don't use CM so I'm not sure what theyre on) do you intend to start up the JW thread you mention in the OP?

EDIT:

Upon rereading some stuff in the PA threads for the n7 and n4 it seems they have a merged version with both JW and JS components, can anyone confirm if this kernel is working on the latest PA? If it is then please disregard my question, Thrace.
[Nexus 4 Android Development] Kocai:
You have to use JWR kernel for the latest PA ROM. But if you want to use JSS kernel, you can flash this zip from [MENTION=3873953]eng.stk[/MENTION] here. It'll replace some lib files in /system/lib/egl and /system/lib/hw

After flashing that file, you can only use JSS kernel otherwise you'll have screen tearing. If you want to revert, I have a revert zip file.
[Nexus 4 Android Development] Kearkan:
Thank you!

I would assume I could revert by wiping /system and reflashing the ROM?
[Nexus 4 Android Development] Kocai:
Yes, you can do that to revert.

Sent from my Nexus⁴
[Nexus 4 Android Development] ciprianruse88:
Rock solid kernel and super smooth.Hoping for more updates to come :thumbup:
[Nexus 4 Android Development] karanrajpal14:
Doesn't seem to be booting for me on PAC man ROM. It's just stuck at the boot animation. Any ideas anyone?
[Nexus 4 Android Development] szucsgf:
Are you coming from another custom kernel? If so, it may help to dirty flash your ROM before flashing this kernel.
[Nexus 4 Android Development] karanrajpal14:
Nah mate. It was a clean flash. It's really odd though, since PAC is a JSS ROM. I think I'll try again today.
[Nexus 4 Android Development] szucsgf:
Is PAC based on CM? I believe CM modifies the ramdisk, with the result that not all kernels work on it.
[Nexus 4 Android Development] karanrajpal14:
Yes I believe it is. Any way I can make this work on PAC?
[Nexus 4 Android Development] szucsgf:
I'm sorry, I don't run a CM based ROM myself so I've never had to look for a solution. In not even certain the cm ramdisk is your problem, but it would be my first guess. Hopefully I've given you a place to start researching.
[Nexus 4 Android Development] veyka:
Flash the anykernel version of the kernel, not the one that comes with a ramdisk and it should boot fine.

If you flashed the kernel already, flash your rom without wiping anything then reflash the kernel
[Nexus 4 Android Development] thracemerin:
Since I've been busy lately and haven't had a ton of time to get things sorted and working 100%, I thought I'd leave this: https://github.com/thracemerin/kernel-Nexus4/tree/m_plus_4.3_AHP here for people to see the progress that is being made.

We should have a testing build sometime this week which will just be auto-hotplug and msm-thermal, if it goes well I'll merge it into the current kernel.

Anyway, stay tuned :D
[Nexus 4 Android Development] thracemerin:
Ok, here's a fairly stable auto hotplug test build that people can try out.

A few caveats:

This is packed in a CM boot.img meaning it will

ONLY

work on CM10.2, don't flash it on something else you will bootloop.

Because of the above, I will only provide it as a boot.img for fastboot.

I haven't modified the powerHAL to ignore the fact that mpdecision is disabled, so your logcat will be filled with spam about touchboost, like lots of spam, so if you're trying to debug something else, be warned.

What's included:

stuff

maybe other stuff

see here: https://github.com/thracemerin/kernel-Nexus4/tree/m_plus_4.3_AHP

Instructions:

reboot to bootloader

fastboot flash boot boot2.img

Note: This will

ONLY

work on CM10.2, not CM based ROMs, not AOSP, not ....

ONLY

CM10.2

Note 2: This is the test build I'm running which is why it's a CM10.2 boot.img, usable

ONLY

on CM10.2

Note 3; Really, don't flash this if you aren't on CM10.2, if you do and bootloop I will laugh at you.
[Nexus 4 Android Development] AcmE85:
Speedwise, I don't notice any difference on first glance.

Unfortunately there seems to be no gamma and undervolting support

in this early state.

Nonetheles I will give it a go for a day to see if there are some bugs.
[Nexus 4 Android Development] thracemerin:
Yeah, it's just auto hotplug and updates to interactive. I wanted to ensure that the auto hotplug is working properly without the potential for bugs related to other stuff.
[Nexus 4 Android Development] AcmE85:
Ok, after a day I noticed two things with the auto hotplug testbuild:

My device was slightly less responsive (I should say slower) in some occasions.

Basically switching between apps, navigating. I didn't play any games.

Also there is a small delay when powering on the screen compared to the stock cm kernel or m_plus a5.

Battery wise, there was no real difference. But more testing should be done in the battery department,

because one day is just to short to judge battery consumption on any kernel.

Right now I am back to a5.
[Nexus 4 Android Development] sirxdroid:
[MENTION=4303511]thracemerin[/MENTION] - once again great work you are doing on these kernels.

Any plans to add support for NFS and CIFS? It would be useful to make backups straight to a NAS when low on space on the device.
[Nexus 4 Android Development] thracemerin:
Yes, I do plan to merge everything from 4.2.2 to 4.3, I'm trying to decide whether I want to go autohotplug or mpdecision before I go any further however.
[Nexus 4 Android Development] hellsgod:
What do you think about something like Touch Boost?

hells
[Nexus 4 Android Development] thracemerin:
autohotplug has touchboost when using interactive.
[Nexus 4 Android Development] sirxdroid:
Which autohotplug implementation are you thinking of using?
[Nexus 4 Android Development] thracemerin:
_motley's version, its in the test build I posted.
[Nexus 4 Android Development] AcmE85:
In case you missed my comment on the auto hotplug build.

Auto hotplug on motleys and m+ with 4.2.2 was definitely smoother than this build.

I believe it will become better because it is only a testbuild after all.

edit: Battery life has not been affected for me with mpdecision on 4.3 compared to

auto hotplug on 4.2.2.
[Nexus 4 Android Development] thracemerin:
Hmm.....I wonder if there was something else in his powerHAL for 4.2.2 other than suppression of the mpdecision spam.
[Nexus 4 Android Development] ctfrommn:
I came across this yesterday while doing my normal scouring of Google's Gerrit...I'm not a kernel guy but maybe this would be of use to you.

https://android-review.googlesource.com/64520
[Nexus 4 Android Development] thracemerin:
Interesting, certainly worth looking at.

Supposedly the CM folks are looking at some stuff from CAF to fix the deadlocks, but I don't know if it's kernel or OS related, nor do I know what commits specifically.
[Nexus 4 Android Development] ctfrommn:
Im not building the kernel so I can't test this commit. This may simply be part of 4.3.1 or a new kernel.
[Nexus 4 Android Development] thracemerin:
I don't get nearly as many deadlocks on JSS15J as other people seem to, no idea why.
[Nexus 4 Android Development] ctfrommn:
I get none....as long as Im on stock or a mpdecision kernel. I havent tried you latest test as I like mpdecision, but I get none on a5.
[Nexus 4 Android Development] thracemerin:
I get them once in a while when trying to type on the AOSP keyboard, but maybe 1-2 a day, some people are saying they get them every time they try to type something.
[Nexus 4 Android Development] AcmE85:
Me too, only once in a while. Sometimes only every second day.

But it also happened on the stock android keyboard.
[Nexus 4 Android Development] ctfrommn:
We switched from AOSP to Google keyboard....seems to work better.
[Nexus 4 Android Development] thracemerin:
Doesn't seem to make a difference on CM, but the couple of deadlocks I get a day don't really bother me.

I'll build a stock kernel with that deadlock fix and see if it makes any difference.
[Nexus 4 Android Development] sirxdroid:
Are these really deadlocks or we just call them that? To me a deadlock is something that's stuck forever, you can't make any more progress. Unless there's some other watchdog that kills one of the parties causing the deadlock. Maybe the kernel has something like that built-in, just like databases do.
[Nexus 4 Android Development] thracemerin:
I wasn't the one who called them deadlocks, so I'm not sure what the definition is in this case. Deadlock in the case we're talking about results all processes hanging for a period of time, given that it doesn't require a reboot to fix I'm assuming you are correct that a watchdog of some sort unclogs the mess and gets things going again, I haven't dug into the exact specifics because this particular issue is a little beyond my pay grade :p
[Nexus 4 Android Development] sirxdroid:
I was not pointing any fingers by any means. I was just curious and trying to spark an educational conversation, hopefully learn something in the process :)
[Nexus 4 Android Development] ctfrommn:
Always starting trouble ;)
[Nexus 4 Android Development] sirxdroid:
Hey, you go back to your (fine) PSX sandbox.
[Nexus 4 Android Development] ctfrommn:
Lol....I was just sharing info with the man here :p
[Nexus 4 Android Development] thracemerin:
I didn't say you did :)

It seems from a little research that for some reason the main kernel workqueue gets locked up resulting in processes in the foreground getting stuck, apparently some things that are being worked on in different workqueues or different threads continue to go, I'm guessing that one of these things is whatever unjams the main workqueue.

Potentially the commit ctfrommn is referring to is the reason that this is happening and if that's the case it might be the fix.
[Nexus 4 Android Development] thracemerin:
I also have to say that this thread and the 4.2.2 one always seem to have the most interesting discussions about bugs, the other kernel threads are never this interesting to read :D
[Nexus 4 Android Development] thracemerin:
Taking this even further, since the JWR kernel doesn't deadlock and the JSS kernel does, one can assume that the problem is related to the 50ish GPU commits that were squashed and inserted into the JSS kernel at the last minute, but exactly how this is a problem I'm not sure.

Edit: this is often the problem with taking 50 commits and squashing them into one, there could be something like a 1 instead of 0 somewhere that's throwing a wrench in the whole thing but it's much harder to debug when you do it like that.
[Nexus 4 Android Development] ctfrommn:
Cause youre one of the few devs who actually respond and do something about the issues. Keep being one of the good ones! :)
[Nexus 4 Android Development] FeintDoxx:
ERMMM

So after being on your kernel on 4.2.2 for the longest time, i finally switched over to 4.3 JS. I had some weird things going on, google services used up 3.3 gbs of Data in less than a week :eek:

Just download the a5 anykernel since im on CM10.2. this should be fun!:victory:
[Nexus 4 Android Development] thracemerin:
CM has had some issues with the Google OTA updater going crazy and trying to download the OTA and install it over CM resulting in some unusual data usage by Google Services, it should be fixed now, but you might have to wipe to fix it completely, I'm reasonably sure that it's not kernel related.
[Nexus 4 Android Development] FeintDoxx:
I wasn't accusing your kernel! :eek: haha It just gave me a reason to finally go to 4.3. I figured it had to do something with the OTA so I figured might as well flash stock image start from scratch and go to CM 10.2. I'm liking it so far going to flash A5 after I post this.
[Nexus 4 Android Development] thracemerin:
Yeah, I figured I'd make sure everyone knew it wasn't kernel related, didn't say you were saying it was :)
[Nexus 4 Android Development] FeintDoxx:
Ah okay haha. Biggest downside of this is that this dumb bug used up 3.3gbs out of my 4.5gb of high-speed data. Capped data speed here I come :banghead:
[Nexus 4 Android Development] _Behemoth:
Can someone tell me if I need to flash the 4JS ramdisk version followed by the 5JS or do I just flash 5JS?

What good does init.d support do?
[Nexus 4 Android Development] FeintDoxx:
Read this.