MobileRead Forums - View Single Post

tshering · 09-20-2016, 04:36 AM

@oldhasbeen
I think there is nothing that should be needed to be suspended. KSM is rather a bundle of scripts and binary executables, than one executable. When you start an(other) application from KSM, no KSM binaries are kept running, but only scripts.

When you see the KSM main menu on the screen, the following KSM executables are running:
adds/kbmenu/onstart/ksmhome.sh
adds/kbmenu/onstart/kobomenu.sh
adds/kbmenu/kobomenu # This is the binary executable, the one that consumes power.

When KOReader is running, then from the KSM side, there are running:
adds/kbmenu/onstart/ksmhome.sh
adds/kbmenu/onstart/start_koreader.sh

When nickel is running, then from the KSM side, there are running:
adds/kbmenu/onstart/ksmhome.sh
adds/kbmenu/onstart/start_nickel.sh

Note: On default, there is one further KSM script running in the background, namely adds/kbmenu/onstart/preventfreeze.sh. You can disable it with the "configure" menu. (This needs rebooting to become effective, if I remember correctly).

As to your report on https://github.com/koreader/koreader/issues/2239, I guess you started nickel from KSM. If this is correct, then I would see the whole picture in this way: The binary kobomenu and KOReader have each about the same power consumption, when idle (10 or 12-13 mA average). Since both do basically the same job in this situation, I guess, namely waiting for user input, that seems reasonable. The outstanding thing is that nickel does the same job (waiting for user input) more efficiently.

09-20-2016, 04:36 AM	#243
tshering Wizard Posts: 3,489 Karma: 2914715 Join Date: Jun 2012 Device: kobo touch	@oldhasbeen I think there is nothing that should be needed to be suspended. KSM is rather a bundle of scripts and binary executables, than one executable. When you start an(other) application from KSM, no KSM binaries are kept running, but only scripts. When you see the KSM main menu on the screen, the following KSM executables are running: adds/kbmenu/onstart/ksmhome.sh adds/kbmenu/onstart/kobomenu.sh adds/kbmenu/kobomenu # This is the binary executable, the one that consumes power. When KOReader is running, then from the KSM side, there are running: adds/kbmenu/onstart/ksmhome.sh adds/kbmenu/onstart/start_koreader.sh When nickel is running, then from the KSM side, there are running: adds/kbmenu/onstart/ksmhome.sh adds/kbmenu/onstart/start_nickel.sh Note: On default, there is one further KSM script running in the background, namely adds/kbmenu/onstart/preventfreeze.sh. You can disable it with the "configure" menu. (This needs rebooting to become effective, if I remember correctly). As to your report on https://github.com/koreader/koreader/issues/2239, I guess you started nickel from KSM. If this is correct, then I would see the whole picture in this way: The binary kobomenu and KOReader have each about the same power consumption, when idle (10 or 12-13 mA average). Since both do basically the same job in this situation, I guess, namely waiting for user input, that seems reasonable. The outstanding thing is that nickel does the same job (waiting for user input) more efficiently.