View Single Post
Posts: 3,074 | Thanked: 12,964 times | Joined on Mar 2010 @ Sofia,Bulgaria
#1445
Originally Posted by Estel View Post
Back on topic, please?



What about ones amongst us, (including me) using jacekowski's modified binary?

We've fmtx already working on max power, so including such a path won't bring any "overwriting" harm?
It will, the default value set on system startup should be 112(the same as stock). You should change that in event.d script to the value you want it to be. The default can be changed too (to max of 120), it was me who insist on using 112 as default during installation.

This may be dumb question, but personally, I don't like overlapping "features". I'm asking this, cause chances are high, that many patches from here will end up in kp49.
While I fully agree that overlapping features is silly what about us not using the above mentioned binary?

fmtx .ko module exposes ioctls to userland for reducing and increasing power. Stock fmtxd uses those ioctls to manage fmtx power every time a charger/usb cable is connected to the device. The previous patch (the one from KP46) simply disables locking of sys/.../power_level , but does not prevent fmtxd to set power_level via ioctl.

Just for clarity - fmtx patch makes all fmtx power applications unneeded - once set, fmtx power level remains constant until reboot.

TBH i was not sure that fmtx patch should be included, but future maintainer's words were "release early, release often"
 

The Following 3 Users Say Thank You to freemangordon For This Useful Post: