[Asus ZenFone Max Pro M1  ROMs, Kernels, Recoveries] Rasenkai99:
FAQ :

[B]1. What is EAS?[/B]
-> EAS expands to "Energy Aware Scheduling".
It is somewhat new to android systems, and bases on the concept of completely fair scheduling.
Before getting too excited, one should understand what exactly it is.
Even if the name gives out vibes of some energy saving system which can drastically improve power consumption, that is not exactly the case.
EAS is basically a system of task scheduling, just like HMP which ships by default in our devices. EAS can be considered superior to HMP for a set of reasons even if HMP does have its own merits.
Unlike HMP, EAS is "energy-aware". The "energy saving" comes into play when the tasks are scheduled to the core and ramped to the frequency that is suited to proceed with the task.
So rather than an "energy-saving system", it is more apt to be recognized as something that reduces excess or needless power consumption for a given task.
For such proper scheduling, a proper "capacity-cost model" is necessery.

[B]2. What is a "capacity-cost model"?[/B]
-> The is the scheduler is made aware of the power consumed by each cluster and core at each frequency available for operation through something we call the "capacity-cost model". It doesn't have to be 100% accurate but must be at least be accurate enough to properly let the scheduler clearly know what a particular cpu at a partical frequency can do at the expence of roughly what amount power. SDM636/660 does not have a "authentic" energy-cost model from CAF or any other reliable source. Hence we are using a model we calculated thanks to people like kDrag0n, Zachariah, Joshuous etc.

[B]3. Why EAS?[/B]
-> EAS is gernerally considered superior to HMP for it's responsiveness to loads and smarter placement of tasks in a system. EAS is better at deciding what tasks reside on the Big and Little clusters. EAS ensures optimal power consumption for optimal performance without overshooting either of those. EAS governors, mainly Schedutil does not require setting up a long list of tunables for optimal performance. A well set up EAS system should diminish performance drops in handling tasks at the same time consuming the right amout of energy.

[B]4. The Boost set up in Muffin is weird![/B]
-> Boosting is an integral part of EAS because of the way it is set up. Boosting helps increase the time allocated for the concerned task. We mainly boost the "top-app" schedtune group which essentially is the set of tasks that is resposible for the things user interacts with.
Usually boosting is handled by userspace entities like the power-hal. But since we do not have the luxury of ROM side changes for EAS, we use in-kernel modules for boosting. That is why muffin has a long list of boosting options. By default the boosting is set for a satisfactory level of smoothness.
The set up has been tested for its performance and battery life by members of our testing group returning a satisfactory feedback. Users can bump it up or down as per their requirement if they feel the default set up is not their piece of cake.

[B]5. Is Muffin proper EAS?[/B]
-> Muffin is "proper" EAS if what that refers to is:
1. An energy-model set-up
2. Active EAS scheduler
3. Schedtune interface
4. Working boost mechanism.

Muffin is not "proper" EAS if that refers to:
1. Employing an 'authentic' capacity-cost model.
2. Power-hal based boosting
3. Big names behind the kernel.

Since the kernel is open for all to use, why not give it a try and check if it meets the standard you expect from the kernel. If it does, we are extremely happy.
If it does not, you are obviously free to ditch the kernel and opt one that suits your requirements.
X00T/D/DA has a wide range of kernels with most excelling at its business.
You probably will never run out of options to try.

[B]6. Charging rate seems low.[/B]
-> Muffin supports charging standard 5V/2A which is what our device has support for.
The device should intake upto 2A[in theory. More like max: 1.9A in practice] as long as the temperatures do not exceed the threshold values of charging throttle mechanism.
We are not confident enough to bump up the intake for obvious concerns over safety, sustainability and reliability.
We do not ship any charging hacks or pseudo quick charge implementations, for the better or worse depending on what side you are on. Essentially, we are playing it safe.

[B]7. Battery life/Performance needs improvement.[/B]
-> Muffin is not specifically oriented either for extreme battery life or extreme performance.
So expecting either of those may leave you disappointed. We aim for a fair amount of smoothness for fair level of power consumption.
We are not ready to sacrifice either of those in favor of the other.
But we are obliged to make sure that the kernel does not induce excess, unacceptable battery drain or degraded performance. We'll be working on improving both performance and battery as long as they do not feed on each other.

[B]8. Muffin has _________ bug || ______ doesn't work properly on Muffin.[/B]
-> Bugs and issues are common in custom kernels.
We are by no means pro's at the job and may mess things up at times. But we do let the kernel go through a bunch of testing by the members of our Testers' group, so the chances of major bugs existing in the release builds is comparitively low.
However if you do end up facing bugs, please do report it to us through our support group or tagging us on TG[ @ajaivasudeve || @rasenkai] in device groups where we are active members of as long as other members of the group are okay with it.
Even if you are not in a state to give any logs or detailed description, at least mentioning it to us briefly would help us a lot.

[B]9. Supported ROMs[/B]
-> We do not limit support to a set of specific ROMs. We aim for maximum compatibility from our end.
But due to ROM side changes, flashing the kernel on some ROMs may trigger some kinda misbehaviour.
The chances of that happening is not that high but may be the case if you are experiencing uncalled lags, battery drain or other annoying occurances.
In that case we recommend to either opt for a different kernel or return to the stock kernel of the ROM