View Single Post
Old 06-06-2019, 11:33 AM   #140
NiLuJe
BLAM!
NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.
 
NiLuJe's Avatar
 
Posts: 13,478
Karma: 26012494
Join Date: Jun 2010
Location: Paris, France
Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E
Released 1.3.0!

Some major QoL changes this time around: KFMon will now pickup updates to watch configs right after an USBMS session, you no longer need to restart the device . This works for updates to existing watches, additions of new watches, and removals of existing watches (basically, everything ;p).

For people who maintain custom KFMon settings (nowadays, that'd mainly be to switch to syslog logging), you can copy your kfmon.ini to kfmon.user.ini, it'll be parsed after the default config, and will persist across KFMon updates .

In case you ever need to temporarily prevent KFMon from spawning *anything*, you can now do so by simply dropping a blank BLOCK file in the config folder.

In a watch config, the action & filename fields are now put through a more obvious validation process, which will put relevant info in the log in case of failures.

Speaking of failures, a broken watch config will no longer cause KFMon to abort, that watch will now simply be ignored.

Also includes the usual boring FBInk, SQLite & inih updates, as well as some slightly more significant than usual tweaks & cleanups to the code & buildsystem .

On the "fun experiment" side of things, you can now optionally replace the boot progress bar with a custom, faster alternative. This is not being done by default because it's both visually intrusive (since it looks different), and because it *may* be problematic with some specific custom setups (mainly, older FW versions, or people who don't boot straight into Nickel). You can try it out by dropping a blank BAR file in the config folder, but do see the final FAQ entry on GitHub for more details first.
On my devices, it does shave a nice ~10% off Nickel's boot times, which is always appreciated .

This started as a random experiment, which I put more thought into when I realized that it could work, and that Kobo's default progress bar was chewing through 50% of CPU time to essentially draw 5 squares in the middle of the screen, which seemed fairly ridiculous, and meant than replacing that could net me some actual tangible gains in terms of boot times.

Last edited by NiLuJe; 06-06-2019 at 11:38 AM.
NiLuJe is offline   Reply With Quote