Kobo Start Menu

[trekk]

Hm, I installed the Kobo Patcher in both variants. This is one difference, but I don't know how this could be related to the problems. I will start some testing at the weekend with a reset device.

[enotar]

I use this on Kobo touch old version and use post 78 to install.
Sometimes kobo boot in menu sometimes in Nickel, no pattern on when which one.
Any idea?
Thank you

[tshering]

Originally Posted by trekk

Hm, I installed the Kobo Patcher in both variants. This is one difference, but I don't know how this could be related to the problems. I will start some testing at the weekend with a reset device.

I don't think the modifications done by the patcher matter. They concern only nickel. KoboLauncher/VlasovsoftLauncher and KOReader should also have no influence, since they are not yet active at the point when the menu has already its problems. I only asked for all installed hacks, because I thought this is the easiest way to see a common pattern in those devices that have the problem. On guess was that Giorgio's multi touch hack might be the culprit. but according to your report, this is not the case.
Another difference in the setup could be that some people installed the full 3.2.0 update package, and some only the KoboRoot.tgz.

[tshering]

Originally Posted by enotar

I use this on Kobo touch old version and use post 78 to install.
Sometimes kobo boot in menu sometimes in Nickel, no pattern on when which one.
Any idea?
Thank you

Did you make the change in runsittings.txt as described in post 78? Select in the main menu "scripts," then "activate," then "set run menu settings.msh," the "always." After that the menu should be started with every power on.

[enotar]

Originally Posted by tshering

Did you make the change in runsittings.txt as described in post 78? Select in the main menu "scripts," then "activate," then "set run menu settings.msh," the "always." After that the menu should be started with every power on.

My bad.
It works
Thank you

[Ken Maltby]

Originally Posted by tshering

I don't think the modifications done by the patcher matter. They concern only nickel. KoboLauncher/VlasovsoftLauncher and KOReader should also have no influence, since they are not yet active at the point when the menu has already its problems. I only asked for all installed hacks, because I thought this is the easiest way to see a common pattern in those devices that have the problem. On guess was that Giorgio's multi touch hack might be the culprit. but according to your report, this is not the case.
Another difference in the setup could be that some people installed the full 3.2.0 update package, and some only the KoboRoot.tgz.

For the record I installed the whole package, for the upgrade of my AuraHD to FW 3.2.0.

Luck;
Ken

[tshering]

Originally Posted by Ken Maltby

For the record I installed the whole package, for the upgrade of my AuraHD to FW 3.2.0.

Thank you! I think this falsifies another suspicion of mine.

[trekk]

Originally Posted by tshering

On guess was that Giorgio's multi touch hack might be the culprit. but according to your report, this is not the case.

I installed Sergey's pbchess on a clean 3.2.0 install on my Aura HD. Launcher and CoolReader worked like a charm, no problems with a non responsive touchscreen, no problems with a wrong orientation.

I installed KBStartMenu_03check then. This also worked like a charm! The screen responded to touches, no more flipping.

Next I installed KoboMultiTouch320. After a reboot your start menu showed up. I was able to select any menu entry, but apart from getting highlighted nothing else happened. Your guess seems to be right!

Uninstalling KoboMultiTouch didn't fixed this. I started nickel and Sergey's launcher, but the screen stayed unresponsive.

[tshering]

Originally Posted by trekk

I installed Sergey's pbchess on a clean 3.2.0 install on my Aura HD. Launcher and CoolReader worked like a charm, no problems with a non responsive touchscreen, no problems with a wrong orientation.

I installed KBStartMenu_03check then. This also worked like a charm! The screen responded to touches, no more flipping.

Next I installed KoboMultiTouch320. After a reboot your start menu showed up. I was able to select any menu entry, but apart from getting highlighted nothing else happened. Your guess seems to be right!

Uninstalling KoboMultiTouch didn't fixed this. I started nickel and Sergey's launcher, but the screen stayed unresponsive.

Thank you, Trekk! I think the KoboMultiTouch uninstall does not work on FW 3.2.0, because the name of the sub directory has changed. Instead of the update folder provided by Giorgio, one should use the update folder provided in kobo-update-3.2.0.zip (mark 4).

[Lucas Malor]

This is a very good tool. I'll try it very soon, it's a good and safer alternative to Kobo File Monitor. Some random suggestions:

1. please do not overwrite directly rcS, it's not safe. Use yoq's trick instead (look at Night Mode under etc/udev) and move what you can in a separate script.
2. You also overwrite also /usr/local/Kobo/udev/usb. Can't you rename your "usb" exec?

Thank you and good Kobo !

[tshering]

Thank you Lucas for your nice words and suggestions.

Originally Posted by Lucas Malor

it's a good and safer alternative to Kobo File Monitor. Some random suggestions:

I cannot see why the Kobo File Monitor is not save, provided it is correctly configured. Besides that it has a functionality that the Kobo Start Menu cannot offer. But yes, for same tasks the Kobo Start Menu is the better choice.

I will keep your suggestinos in mind for possibly future versions, but would like to say already now some words in response.

Originally Posted by Lucas Malor

please do not overwrite directly rcS, it's not safe.Use yoq's trick instead (look at Night Mode under etc/udev)

I cannot see why overwriting the rcS file with a version that I have tested should be less safe than modifying it on the fly by a script (especially since I cannot know exactly what changes a user might already have done to her rcS file). On top of that, it is not very practical to modify a file by a script if the changes are numerous.
As I understand it, the advantage of Yoq's "trick" is that he can install his night mode and preserve at the same time all modifications a user might have done to the rcS, and also not to have to deal with changes that Kobo might introduce in future rcS files (apart from the one line he is concerned with). I cannot see that this has much to do with safety.

Originally Posted by Lucas Malor

and move what you can in a separate script.

As to your suggestion of moving as much of my code to an external file, that was my original plan. I gave it up because finally I had not only to insert code at different points of the script, but also to modify the already existing code at several points. I therefore see not much point in splitting the code up.

Originally Posted by Lucas Malor

You also overwrite also /usr/local/Kobo/udev/usb. Can't you rename your "usb" exec?

What would be the point in doing so?

Thank you for suggesting to include the start menu into the List of Tweaks / Hacks / Mods.

[Lucas Malor]

Originally Posted by tshering

I cannot see why the Kobo File Monitor is not save

File Monitor is safe, but not if used for launching GUI programs. You have to sleep nickel process, and this is problematic if the program you've launched crashes or hangs. It happened to me, I had to wait the battery end-of-life and database gets corrupted.

Originally Posted by tshering

As I understand it, the advantage of Yoq's "trick" is that he can install his night mode and preserve at the same time all modifications a user might have done to the rcS, and also not to have to deal with changes that Kobo might introduce in future rcS files (apart from the one line he is concerned with). I cannot see that this has much to do with safety.

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.

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.

About PRODUCT, PLATFORM and this lines of code, I think you can move them in your external script without problem:

PHP Code:

echo 1 > /sys/devices/platform/mxc_dvfs_core.0/enable 


PHP Code:

if [ -e /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 ) & 


Originally Posted by tshering

What would be the point in doing so [renaming "usb"]?

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.

[tshering]

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.

Originally Posted by Lucas Malor

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).

Originally Posted by Lucas Malor

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.

Originally Posted by Lucas Malor

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.

Originally Posted by Lucas Malor

About PRODUCT, PLATFORM and this lines of code, I think you can move them in your external script without problem:

PHP Code:

echo 1 > /sys/devices/platform/mxc_dvfs_core.0/enable 


PHP Code:

if [ -e /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?

Originally Posted by Lucas Malor

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.

[PeterT]

I wonder if there might be a benefit to rather than changing rcS, to alter /etc/inittab to have a "custom" file for the ::sysinit: entry?

Either copy the original rcS to this new file and edit the new file, or, supply a total replacement to rcS with only the portions desired in it.

[Lucas Malor]

@tshering: If you want to prevent updates you can add your script invocation before update check and simply rename KoboRoot.tgz. The firmware will be installed if you restore KoboRoot.tgz and exit Start Menu.

Originally Posted by PeterT

I wonder if there might be a benefit to rather than changing rcS, to alter /etc/inittab to have a "custom" file for the ::sysinit: entry?

The problem is that many partitions are mounted in rcS. If you want to access the entire filesystem you have to hack it.