[Sprint  Galaxy Note 4 Original Android Development] ffolkes:
TW version still coming, but now that MM is out it's on hold. Also, since CM 13 is very stable, support for CM 12.1 has been discontinued. A lot of work has gone into this latest release, I hope it works well for you guys. I have been getting great battery life with it!

If you want to donate, here is the link. All donations are appreciated! :)

If you don't want to reset Synapse, make sure to do the following after flashing the new kernel:

Reset the ZZMoove Scaling tab to defaults. Press the dotted square icon with 4 little squares in it, tap the 3-dot icon, tap "Select all in section", tap the curved arrow icon, then press Apply.

Reset the ZZMoove Hotplug tab to defaults, using the same method as described above, except do it on the hotplug tab.

Plasma 1.21-AOSP for Marshmallow 6.0.x (CM 13, CMRemix)

Experimental: Dynamic Foreground Process Affinity - The theme of this version of Plasma kernel has been thinking outside the box. We've all been hearing a lot about big.LITTLE configurations in the mobile world lately, and that has been trickling down into the legacy device kernel world with things like 'cpusets'. However, this has limited use for SoCs with identical cores, although theoretically we can gain performance by grouping different natured processes together - eg. having system related tasks run on designated cores, and active apps on another. This appears to be in mainline Marshmallow. For a big.LITTLE setup, this is very advantageous as you can get those less important jobs over onto the weaker processors. But that's a moot point for our older processors, since all 4 cores are the same. This is where things get interesting. The heavily modified ZZMoove that is at the heart of Plasma kernel has been designed to favor certain cores for boosts. You may have noticed most Input Booster items have a setting to control what cores get boosted, namely doublepunches and micropunches. Until now this has had a major flaw - boosting a specific core is pointless if the foreground work is being done on a different processor. To put it a different way: what good is boosting core 0 to 1400 MHz, when the app you're interacting with is running on core 3, and that core is only running at 300MHz? That introduces lag, as you'll have to wait for that core to scale up, and making the boost on the other core a pointless waste of power. Worst of all, the scheduler could move that process over to another core at any time. So the only solution thus far has been to boost all cores equally, otherwise it's a game of roulette as to whether or not you'll be running on a boosted core - this means most of the time 3 out of 4 cores are boosted when they don't need to be. That's where 'Dynamic Foreground Process Affinity' comes in. The app that is currently in use will be automatically affined to the core(s) chosen on the [CPU] tab of Synapse. By default, this is set to cores 0 and 1 only. That means any app you're interacting with will be forced to run on core 0 or core 1 only, allowing boosts to be focused on these two cores, instead of all 4. Then, when you leave it or switch to another app, the affinity will be reset back to its normal state of "any core. I have had very good results with this system - reliable buttery smooth interactions, at a fraction of the boost needed in prior versions of Plasma.

.

Experimental: Static Process Affinity - Cores 0+1 are always favored by default now, so certain system processes (system_server, surfaceflinger, etc) have been bound to those cores only - no more surfaceflinger ending up on a 300MHz core and causing lag. While this feature can be disabled via the [CPU] tab of Synapse, the list of system processes is hardcoded, and applied on every 5th home button press. However, a user definable list is also available. An annoyance for me is when floating apps (which can't be detected by the Dynamic method above) get sent to a slow core, and are laggy to pop open. Eg., Facebook Messenger. So I added code to my shell script to also read a file (/data/.plasmakernel/affinity_list.txt) and parse a list of process name matches along with what core mask you want to use. Remember, this is a core mask, not a core id. Remember to use it sparingly, otherwise you'll bog things down. Also remember that this is only for "odd" apps that aren't conventionally recognized by ActivityManager - like system processes, or floating apps - normal apps will be dynamically affined, and released when you're not using them.

Example masks:

1 = core 0 only

2 = core 1 only

3 = cores 0+1 only

4 = core 2 only

7 = cores 0+1+2 only

8 = core 3 only

15 = cores 0+1+2+3 (aka all cores, aka pointless)

Example /data/.plasmakernel/affinity_list.txt that affines any process with 'appdialer' in its name to cores 0 or 1, and any app with flynx in its name to core 0:

appdialer 3
flynx 1

.

ZZMoove: Individual core frequency limits - Each core can now have its own frequency limit set. This is the counterpart to the affinity features discussed above. Now that we know what cores will be used for demanding tasks, it only makes sense to be able to limit the maximum frequency of the other ones - sort of like an artificial big.LITTLE arrangement. By default in 1.21, cores 2 and 3 (aka 3 and 4) are restricted to 2.0 GHz.

.

ZZMoove: Power Saving Mode redesign - There are now many more options for Power Saving Mode, and much of the code has been redone.

.

ZZMoove: Brand new hotplug logic - The old hotplug logic had a few major bugs. I spent a few days experimenting with different ways to do things, and ended up with some big changes. Logic is based on core frequencies only now (no more load, as that was a pointless metric), and bugs in the delaying logic have been fixed. As a result, the [ZZMoove Hotplug] tab has many different default values, so be sure to use Synapse to restore that tab to defaults.

.

ZZMoove: Input Booster normal frequency-step control - During the entire input booster event, you can use this frequency-step.

.

ZZMoove: Input Booster punch frequency-step control - During only the punch part of the event, you can use this one.

.

ThumbControl can ignore a finger on the touchscreen - This took a week to get right. I almost went insane. I don't know how to describe it in words, I'll have to make a video. To put it simply, it allows you to hold a finger on the screen without inputting anything. I made it because in bed I'd hold my phone above my head, and sometimes I wished I could just grab it, ignore further input from that finger, and have the driver treat finger #2 events as coming from the 1st finger.

.

Fixed bug in Touchkey Flicks - I love Touchkey Flicks, and they're more reliable than ever - I use them all the time. I plan on making a video very soon, since I doubt most people even know what they are.

.

Fixed bug in camera autodetect

Fixed bugs with buttons - Hopefully should fix problems with screenshot key combos.

AOSP: Added Netflix fix to [Actions] tab - To make life easier.

AOSP: Improved crashed camera driver auto-restart - Doesn't always work, but does sometimes at least.

AOSP: Improved lockscreen detection (for camera launch) - Launching the camera pragmatically is very slow when the lockscreen is up, it takes like 10 seconds. However the camera shortcut can do it instantly. So there is a code to check to see if the lockscreen is up, and if so, instead of running the camera command, it'll simulate a swipe up on the camera icon.

AOSP: Fixed LED control not working