Thread: Kobo Start Menu
View Single Post
Old 03-30-2014, 06:15 PM   #118
tshering
Wizard
tshering ought to be getting tired of karma fortunes by now.tshering ought to be getting tired of karma fortunes by now.tshering ought to be getting tired of karma fortunes by now.tshering ought to be getting tired of karma fortunes by now.tshering ought to be getting tired of karma fortunes by now.tshering ought to be getting tired of karma fortunes by now.tshering ought to be getting tired of karma fortunes by now.tshering ought to be getting tired of karma fortunes by now.tshering ought to be getting tired of karma fortunes by now.tshering ought to be getting tired of karma fortunes by now.tshering ought to be getting tired of karma fortunes by now.
 
Posts: 3,489
Karma: 2914715
Join Date: Jun 2012
Device: kobo touch
Thank you for sharing you insights. I it is getting late now, so I will not answer each of your points in detail, but only say a few words.

Quote:
Originally Posted by Lucas Malor View Post
You can't know whow rcS will be modified in a future. For example it could export a variable that it's crucial for another system script. Indeed if you compare your rcS with the last one you can see much lines of codes you missed, most notably the code that adds a factory reset check.
Right, I don't know what changes the rcS will undergo in future. And this is true even if I do my modifications via a script. That my rcS will possible fail in a future version, is a risk I take (and expect the users to take if they use the menu).


Quote:
Originally Posted by Lucas Malor View Post
Indeed if you compare your rcS with the last one you can see much lines of codes you missed, most notably the code that adds a factory reset check.
Actually, I did this on purpose. If you reinsert the code and power the device on several times in a row without starting nickel, you will find out why I did so.

Quote:
Originally Posted by Lucas Malor View Post
The good news is that if you'll do such an installer, you don't need all the modifications you're doing, because you don't need to modify the update process. You have only to modify the yoq's installer so it does not remove itself and it doesn't apply if it's already applied. So even if the system will be upgraded, Start Menu will be automatically reapplied on the new rcS.
The main reason for modifying the update process is to have the choice of allowing or refusing FW updates.

Quote:
Originally Posted by Lucas Malor View Post
About PRODUCT, PLATFORM and this lines of code, I think you can move them in your external script without problem:
PHP Code:
echo > /sys/devices/platform/mxc_dvfs_core.0/enable 
PHP Code:
if [ -/usr/local/Kobo/plugins/gfxdrivers/libimxepd.so ]; then
  export QWS_DISPLAY
=imxepd
else
  
export QWS_DISPLAY=Transformed:imx508:Rot90
  export QWS_MOUSE_PROTO
="tslib_nocal:/dev/input/event1"
fi 
Ultimately, what you have to substitute in rcS is only
PHP Code:
usleep 400000; /etc/init.d/on-animator.sh ) & 
with
PHP Code:
export PRODUCT
export PLATFORM
/path/to/my/external/script

usleep 400000; /etc/init.d/on-animator.sh ) & 
I know that I could shift SOME of the code to another file, but not all. And it is a lot more than you think, if I don't want to lose functionality. So why should I do it?

Quote:
Originally Posted by Lucas Malor View Post
For the same reason above. The original "usb" file should remain untouched since it's used by nickel and you can't know how it will be modified in a future. On the contrary your program should use a "myusb" file.
The changes are to prevent forced FW updates in older versions of the FW. The start menu itself does not use the usb file.

Thank you again for your concern.
tshering is offline   Reply With Quote