Quote:
Originally Posted by Zekathon
Yes, i understood it.  koreader has a bug, which under certain condition causes a drain of the battery, because of incorrectly set sleep flag somewhere in the code. Furthermore, it generally consumes more, then Nickel interface, which is understandable given the simplicity of Nickel.
What i was referring to, was one of the responses saying that the KSM is running in the background. Of course the main consumer is the KOR, but the KSM has to be draining it too, as the process never stops and awaits an event. I am not saying, that it the main cause, but surely it has its own part in the process. |
First, KSM doesn't work like that. It starts whatever reader you want (and have installed on your device) and stop using processor. Including nickel. If it started nickel and continue to drain battery, then you would see higher battery drain with nickel also (nickel is also started with KSM, if you didn't know that). Which is not the case. So, I hope you see now, obviously tells us all that KSM isn't culprit.
Second, if you read issue, culprit for false sleep is a bit more (a lot more) complicated. Maybe now when suspend script is written in lua would be solved. It remains to be seen.
Third, nickel uses less battery when reading not because it is simpler software, but because it is written in such fashion that after user turns page he goes in sleep and only leaves IR active waiting for next user input.
Koreader doesn't enter sleep mode when it is on. Maybe some day it will, it is theoretically possible to program it to behave like that.
This a bit higher battery drain when reading isn't that big that it makes that big difference. Especially with KA1 which usually also uses battery for light (which obviously couldn't be stopped in periods when device waits for user input).