Kobo Start Menu 09

[NiLuJe]

Bonus points if you fix KSM to actually use the proper current fb orientations on (at least) Mk. 7 devices, because that's currently not the case .

(That part is accurate in FBInk, because KOReader relies on it, c.f., utils/fbdepth.c, with extensive comments about the exact behavior on the devices I own, scattered around set_kobo_quirks() in fbink_device_id.c and initialize_fbink() in fbink.c, with a bit of extra posssibly-not-entirely-accurate fun thrown in around rotate_touch_coordinates()).

If that's actually a viable approach with Sergey's Qt4 plugins, of course. Because they may assume and expect the broken behavior, but I wouldn't know about that .

[rtiangha]

Originally Posted by NiLuJe

And, yeah, pickel was recently updated (basically since the new spinner, so, 4.17 or something) with a new, simpler coordinates syntax. Which means I would *assume* it doesn't support the old syntax anymore, and older versions won't handle the new syntax.
Newer pickel variants also expect the various PLATFORM & co env vars to be set properly (which the default rcS does just fine, so that's only a concern if you use pickel on its own without a proper env setup), which wasn't always the case in (much) older FW versions.

OK, keep in mind that I actually don't understand what all of this stuff does (yet, anyway; still trying to find my bearings with this Kobo stuff), but I've been running KSM09 since 3.19 on my Glo HD and am running 4.18 now and I don't think anything has blown up (or if it has, I've never noticed). So does that mean that the old coordinate system still works? Or is it because KSM launches things differently (again: haven't traced enough code to have an idea on how all this stuff works yet, lol; sorry if the question sounds stupid).

[rtiangha]

Originally Posted by NiLuJe

Bonus points if you fix KSM to actually use the proper current fb orientations on (at least) Mk. 7 devices, because that's currently not the case .

OK, I don't have a Mark 7 device so I don't know what the issue is or what expected behavior is, but I'm guessing there's a rotation switch that gets toggled and stores the value somewhere? So it'd be a matter of getting KSM to either read this value and respect it, and/or set it itself and hope that when nickel (or whatever; koreader or plato) loads, it respects that value?

Do we know where this value or state is set or stored? And do Kobos run X? Or is it all virtual framebuffers? If it's virtual framebuffers, can something like fbcon and looking at what's in /sys/class/graphics/fbcon/ help? Can you pass kernel arguments through uboot? Or is the issue that the display orientation doesn't match the touchscreen orientation (and/or the orientation the application expects)?

I dunno, I'm just throwing ideas out there; still just looking around and absorbing; enjoying your code comments, btw. :P

[rtiangha]

Ah, ok. I found your Plato conversation. Wow, what a mess.

Well, since KSM is all shell scripts, I'm guessing that echo'ing various values to /sys is probably the way to go (I see references to /sys/classes/graphics/fb0 so there's that; does the touchscreen driver have something similar or is the touchscreen orientation fine as is?).

The thing is, I only have a Glo HD so I don't know what expected behaviour is supposed to be on other devices or what needs fixing. Do all Mark 7 devices boot/display differently when it comes to rotation? What is the ideal outcome supposed to look like? I'm not sure if I can actually take a stab at this until I get a Mark 7 device of my own since it'll make the testing hard without one.

[NiLuJe]

There are very few commonalities, and they rarely make sense ^^.

Going via sysfs *should* behave like an ioctl on *current* FW versions, but it was possibly extra broken for quite a while during the 32bpp migration (early 4.x until basically 4.9). Take that with a grain of salt, I haven't been testing sysfs *writes* in quite a while.
Reading it appears to be sane, though.

Can't ask the kernel to rotate the touch coordinates for us, AFAICT (and, it is, in fact, "broken" (as, in, rotated) on purpose in the kernel driver for... reasons).

[NiLuJe]

Also, keep in mind that I despise the 16bpp modes with every fiber of my being, so that's *NOT* what I'm most concerned about in FBInk, while it *is* for KSM (and, to a much lesser extent now that it does hw rotation on its own, Plato), because, for historical reasons, it expects/emulates the state the device is put in by pickel during the boot progress animation.

I, thankfully, was more concerned about the state *nickel* puts the device in, and once the move to 32bpp was finalized, that turned out to be a boon, because everything was by then slightly less insane.

(That basically explains why the Plato and FBInk links I quoted above might in fact be referring to slightly different things as the "native" orientation ).

If you want more details about your specific device, dropping a couple FBInk calls at key points in the boot process should make everything clearer (current FBInk versions can log to the syslog). Basically, you want one before on-animator.sh runs for the actual, true, "boot" rotation, which may or may not match the touch orientation, then you want one *during* (as in, after its first iteration, but before nickel kills it) on-animator.sh to see how pickel modifies that, as that's what KSM probably wants to match.
And you want one once nickel has fully initialized to check how it decides to sanitize that to a Portrait orientation.

[tshering]

A random remark:
adds/kbmenu/onstart/checkinstall.sh presuposses the existence of adds/kbmenu/Qt/plugins/mousedrivers/. If this directory is not provided by the package, one has to make KSM create it by itself.

[rtiangha]

OK, just straight up copying the coordinate data from 4.19 seems to work (or, at least it boots and launches nickel fine; I can't tell if there's a difference or not, and I'm still not sure what that stuff does).

However, the libKoboTS.so mouse driver from the forma package (date 1/26/2019) doesn't work on my Glo HD; I had to revert to the one that came in the KSM09+update001+nightmode version that was posted by CH23 (date 10/14/2014) before touch in KSM09 would work again. I don't have any other hardware to either test the other drivers, or if the 1/29/2019 version of the libKoboTS.so driver works on the same devices as the 10/14/2014 version (i.e. Mark 6 devices and older) outside of the Glo HD.

But the Feb 2019 version of vlasovsoft launcher has always worked for me, and it has the 1/29/2019 version of that driver, right? So I don't know what's going on, unless vlasovsoft launcher has never used the newer version of that driver and just uses whatever KSM booted with (i.e. the older one)?

[tshering]

Originally Posted by rtiangha

OK, just straight up copying the coordinate data from 4.19 seems to work (or, at least it boots and launches nickel fine; I can't tell if there's a difference or not, and I'm still not sure what that stuff does).

You can see the difference only when your file system is corrupted and dosfsck cannot repair it.

At this point in the rcS file there is a file system check. From a certain FW version onward Kobo added user interaction. If there is a need to repair the file system and dosfsck fails to do so several times, the user is informed about it and given the opportunity to admit or refuse a factory reset. To make the user interaction possible they provided pickel with a new function: /usr/local/Kobo/pickel wait-for-hit $COORDINATES.

KSM checks whether the pickel version available on the device is able to handle wait-for-hit (if [ $(strings /usr/local/Kobo/pickel | grep -c wait-for-hit) -ge 1 ]) or not and acts accordingly :

if  [ $(strings /usr/local/Kobo/pickel | grep -c wait-for-hit) -ge 1 ]; then
  FS_CORRUPT=0
  dosfsck -a -w /dev/mmcblk0p3 || dosfsck -a -w /dev/mmcblk0p3 || dosfsck -a -w /dev/mmcblk0p3 || dosfsck -a -w /dev/mmcblk0p3 || FS_CORRUPT=1
  if [ $FS_CORRUPT == 1 ]; then
	case $PRODUCT in
		kraken|phoenix|star)
			export COORDINATES="200 740 350 150";;
		[...]
		*)
			export COORDINATES="140 600 300 70";;
	esac
	[...]
  fi
else ### if pickel cannot handle wait-for-hit
  dosfsck -a -w /dev/mmcblk0p3
fi

Recently the expected value/format of COORDINATES has changed and I suppose pickel has therefore changed too. To stay backwards compatible KSM would have to distinguish whether pickel expects the old or new format of COORDINATES and provide the appropriate value/format of COORDINATES accordingly.

[tshering]

Originally Posted by rtiangha

However, the libKoboTS.so mouse driver from the forma package (date 1/26/2019) doesn't work on my Glo HD; I had to revert to the one that came in the KSM09+update001+nightmode version that was posted by CH23 (date 10/14/2014) before touch in KSM09 would work again. I don't have any other hardware to either test the other drivers, or if the 1/29/2019 version of the libKoboTS.so driver works on the same devices as the 10/14/2014 version (i.e. Mark 6 devices and older) outside of the Glo HD.

Maybe this is related to the following:

Originally Posted by tshering

The rcS file should also export the device names that vlasovsoft expects (cf. kobomenu_test.sh in the package that is available here.)
Best,
Tshering

The relevant part is

Spoiler:

NAME=`/bin/kobo_config.sh 2>/dev/null`
MODEL_NUMBER=$(cut -f 6 -d ',' /mnt/onboard/.kobo/version | sed -e 's/^[0-]*//')
case $NAME in
  alyssum)  DEVICE=GLOHD    ;;
  dahlia)   DEVICE=AURAH2O  ;;
  dragon)   DEVICE=AURAHD   ;;
  phoenix)  DEVICE=AURA     ;;
  kraken)   DEVICE=GLO      ;;
  trilogy)  DEVICE=TOUCH    ;;
  pixie)    DEVICE=MINI     ;;
  pika)     DEVICE=TOUCH2   ;;
  daylight) DEVICE=AURAONE  ;;
  star)     DEVICE=AURA2    ;;
  snow)
    case $MODEL_NUMBER in
      374) DEVICE=AURAH2O2_v1 ;;
      378) DEVICE=AURAH2O2_v2 ;;
      *)   DEVICE=TOUCH ;;
    esac
    ;;
  nova)     DEVICE=CLARAHD  ;;
  frost)    DEVICE=FORMA    ;;
  *)        DEVICE=TOUCH    ;;
esac
export DEVICE

[ariel026]

Last kobo firmware update disabled KSM on my Clara HD, how do I restore it if KBStartMenu_09_restore.zip is not compatible with this model?

Clara HD is supported by a special version of KSM 9 (including also the "changed start script for Plato 0.4.1+"), which is available here. Thank you to CH23 for testing and uploading the package. Note: Do not install any of the currently available KSM updates (and also not KBStartMenu_09_restore.zip) over this package, since they are not designed for this version.

[rtiangha]

Originally Posted by ariel026

Last kobo firmware update disabled KSM on my Clara HD, how do I restore it if KBStartMenu_09_restore.zip is not compatible with this model?

Here's a version that will restore the files needed from CH23's version for the Clara if those files get accidentally erased after a firmware upgrade.

If you use kobopatch, you could also extract the files and add them to the additional files section of kobopatch.yaml so that they'll also be included in your patch tar ball (saves you from flashing an extra KoboRoot.tgz).

[ariel026]

Originally Posted by rtiangha

Here's a version that will restore the files needed from CH23's version for the Clara if those files get accidentally erased after a firmware upgrade.

If you use kobopatch, you could also extract the files and add them to the additional files section of kobopatch.yaml so that they'll also be included in your patch tar ball (saves you from flashing an extra KoboRoot.tgz).

That worked perfectly! Thanks a lot

[rtiangha]

Originally Posted by tshering

Maybe this is related to the following:

The relevant part is

Spoiler:

NAME=`/bin/kobo_config.sh 2>/dev/null`
MODEL_NUMBER=$(cut -f 6 -d ',' /mnt/onboard/.kobo/version | sed -e 's/^[0-]*//')
case $NAME in
  alyssum)  DEVICE=GLOHD    ;;
  dahlia)   DEVICE=AURAH2O  ;;
  dragon)   DEVICE=AURAHD   ;;
  phoenix)  DEVICE=AURA     ;;
  kraken)   DEVICE=GLO      ;;
  trilogy)  DEVICE=TOUCH    ;;
  pixie)    DEVICE=MINI     ;;
  pika)     DEVICE=TOUCH2   ;;
  daylight) DEVICE=AURAONE  ;;
  star)     DEVICE=AURA2    ;;
  snow)
    case $MODEL_NUMBER in
      374) DEVICE=AURAH2O2_v1 ;;
      378) DEVICE=AURAH2O2_v2 ;;
      *)   DEVICE=TOUCH ;;
    esac
    ;;
  nova)     DEVICE=CLARAHD  ;;
  frost)    DEVICE=FORMA    ;;
  *)        DEVICE=TOUCH    ;;
esac
export DEVICE

OK, I copy/pasted that code into rcS (only on my PC; I haven't pushed that change to GitHub yet since I've been experimenting a bit and need to clean up my tree first) but unless I'm missing something else to do (which I could be), I still couldn't get the touch driver bundled in the Feb2019 vlasovsoft pbchess package to work with my GloHD (nor would any of the other drivers work with it either). I don't have access to any other devices to determine if things work properly with that set on other devices as well or if it's only my device that's weird.

The only other difference I can think of is that I do use the KSM Bouncer functionality since I like forcing people to enter a password on boot. It could be the newer touch driver isn't loaded by then, but things work properly with the older driver so I'm not sure that's it. Unless order matters in the rcS file; I just realized I put that section after the mouse driver part so putting it before that section could be one last thing I could try.

Anyway, other than that and/or bundling that older version of the driver (either replacing the one that exists in the Feb2019 pbchess package, or as a standalone adding a special case just for GloHD to load the older driver if the newer one still works with other Mark 6 and older devices), I'm out of ideas.

Other than figuring out the backwards compatible part with older firmwares (although if you're using a Mark 7 device, I wonder why anyone would want to use an older firmware version, especially if that device is a Forma or Libra since the newer firmwares fix major bugs and the older version of KSM09 works fine on older devices for both new and old firmwares so unfortunately that part is not really a high priority/on my personal motivated interest list to figure out), I think the only thing left to do is figure out how much of update002 is left that is still relevant to migrate over (which I think mostly has to do with usbnet if I'm reading things right) since a good chunk of it seems to have already made it over in later versions of KSM09. After that, it might be worthwhile to try creating a unified KSM09 2019-12 or 2020-01 update roll-up (maybe targeting 4.18/4.19 devices just to make support easier).

[greensoul]

Hi everyone,

I'm having a big issue with my Clara HD. Please excuse me if this is not the right place to post this question, and I'm totally new on this topic.

My story: My friend gifted me a Kobo Clara HD last week. I was trying to learn about the device and found out about the KMS and Koreader application, and tried to install it on my device.

I connected the device to my computer with USB cable, then I copied folder 'kbmenupngs' to the device, unpluged it, saw the pictures on my Clara. Next, I copied the file KoboRoot.tgz into the .kobo folder of the device, then unpluged the device.

Unfortunately, the application (KMS 8) didn't work properly (probably wrong version). When the device finished installing the KMS, the menu appeared with several options, but I could not click and run the 'Start Nickel', nothing happened. Then, about 30s later the device continued and displayed the home screen as normal. I could see all the files /pictures on the home screen.

Then, I did the stupid thing. I decided to delete the files and not using Koreader anymore. I deleted the pictures in the kbmenupngs first, and intended to delete the other files/pictures next. But the other files were automatically gone... Lastly, I reset the device to factory setting, and the problem came up.

After selecting languages, on the next page I must choose to set up either via Wifi, or connecting to computer with USB cable.
- The first option doesn't work anymore... it runs wifi scanning and just closes the window and not showing the next step.
- The second option doesn't work neither, as my computer cannot recognize the device anymore (I tried using different USB ports and different USB cables).

I'm so hopeless now and it seems like I can't use the device anymore... I'm very upset because it's a gift from my best friend... I was so negligent and made lots of stupid mistakes... Can anyone give me an advice to try fix it? I would really really appreciate your help!