NickelMenu: An integrated launcher for Kobo eReaders

[JSWolf]

Originally Posted by John F

And invert screen and light brightness.

I agree.

[John F]

Originally Posted by JSWolf

I agree.

I had the smiley on brightness because I believe it is a pie in the sky request.

[JSWolf]

Originally Posted by John F

I had the smiley on brightness because I believe it is a pie in the sky request.

But it is a good idea if it can be done.

[geek1011]

I'll might take a look if I have time after the patches, firmware investigations, koboutils updates, and some NickelMenu updates. Right now, I'm also working on a major kepubify update, which should be at least 2.5x faster for most people due to some concurrency and zip archive improvements (there's still a bit more room for improvement, since the regexp matching for sentences takes quite a bit of time and can probably be faster if rewritten by hand), will probably also have a web version which works locally and doesn't require sending your files anywhere (it'll be much slower since it's single-threaded, though), will have much cleaner code with better tests, and will correctly detect misnamed HTML files.

Sorry about my lack of response over the last month; I've been extremely busy.

And for kepubify, if anyone wants to see the in-progress code: https://github.com/pgaskin/kepubify/network.

[anki]

I can't run Koreader on the nickel menu. it was working but i thing some of firmware update of Kobo Reader wil it no more work. I see on the menu Generator error and when i click there it shows;

kfmon: error checking '/tmp/kfmon-ipc.ctl': stat: no souch file or directory


---
Do i need to get some last version of Kfmon and how can i update this?

[NiLuJe]

@anki: Yup, reinstall either KFMon or the OCP.

[Cootey]

I’m not sure why I never installed NickelMenu before. I’ve been loving using it this year. Thanks!

I have a question about Telnet. Anybody know why the connection dies in the middle of a session? My Kobo Clara isn’t asleep, yet suddenly the terminal stops receiving commands. If I force quit the session, I can no longer connect via telnet to my Clara. The process seems hung on the Clara (though it functions as an eReader with no issues). I have to power cycle it in order to regain telnet access. Then the connection dies again after a few minutes.

I’m using the default config:

menu_item :main    :Telnet             :cmd_spawn          :quiet:/bin/mount -t devpts | /bin/grep -q /dev/pts || { /bin/mkdir -p /dev/pts && /bin/mount -t devpts devpts /dev/pts; }
chain_success                        :cmd_spawn          :quiet:/usr/bin/pkill -f "^/usr/bin/tcpsvd -E 0.0.0.0 1023" || true && exec /usr/bin/tcpsvd -E 0.0.0.0 1023 /usr/sbin/telnetd -i -l /bin/login
chain_success                        :dbg_toast          :Started Telnet server on port 1023.

Sent from my iPhone using Tapatalk Pro

[sherman]

Originally Posted by Cootey

I’m not sure why I never installed NickelMenu before. I’ve been loving using it this year. Thanks!

I have a question about Telnet. Anybody know why the connection dies in the middle of a session? My Kobo Clara isn’t asleep, yet suddenly the terminal stops receiving commands. If I force quit the session, I can no longer connect via telnet to my Clara. The process seems hung on the Clara (though it functions as an eReader with no issues). I have to power cycle it in order to regain telnet access. Then the connection dies again after a few minutes.

I’m using the default config:

menu_item :main    :Telnet             :cmd_spawn          :quiet:/bin/mount -t devpts | /bin/grep -q /dev/pts || { /bin/mkdir -p /dev/pts && /bin/mount -t devpts devpts /dev/pts; }
chain_success                        :cmd_spawn          :quiet:/usr/bin/pkill -f "^/usr/bin/tcpsvd -E 0.0.0.0 1023" || true && exec /usr/bin/tcpsvd -E 0.0.0.0 1023 /usr/sbin/telnetd -i -l /bin/login
chain_success                        :dbg_toast          :Started Telnet server on port 1023.

Sent from my iPhone using Tapatalk Pro

Have you got WiFi forced on? Kobo is really aggressive about shutting down the Wifi unless you force on. There's a setting in NickelMenu for that (nickel_setting : force_wifi) which you may want to include in your chain.

[NiLuJe]

On Mk. 7, the reader will also suspend-with-the-lights-on pretty aggressively once Wi-Fi is down and the device is unplugged, if you're not actually touching the device and are *in* a book.

[Cootey]

Originally Posted by sherman

Have you got WiFi forced on? Kobo is really aggressive about shutting down the Wifi unless you force on. There's a setting in NickelMenu for that (nickel_setting : force_wifi) which you may want to include in your chain.

I see. It hadn't occurred to me that WiFi may have been shutting off. I could enable ForceWifiOn in 'Kobo eReader.conf', but that will call for more frequent charging.

Do you mean like this?

menu_item :main    :Telnet             :cmd_spawn          :quiet:/bin/mount -t devpts | /bin/grep -q /dev/pts || { /bin/mkdir -p /dev/pts && /bin/mount -t devpts devpts /dev/pts; }
chain_success                        :cmd_spawn          :quiet:/usr/bin/pkill -f "^/usr/bin/tcpsvd -E 0.0.0.0 1023" || true && exec /usr/bin/tcpsvd -E 0.0.0.0 1023 /usr/sbin/telnetd -i -l /bin/login
chain_success                        :dbg_toast          :Started Telnet server on port 1023.
chain_always : nickel_setting : enable : force_wifi

[geek1011]

Originally Posted by Cootey

I see. It hadn't occurred to me that WiFi may have been shutting off. I could enable ForceWifiOn in 'Kobo eReader.conf', but that will call for more frequent charging.

Do you mean like this?

menu_item :main    :Telnet             :cmd_spawn          :quiet:/bin/mount -t devpts | /bin/grep -q /dev/pts || { /bin/mkdir -p /dev/pts && /bin/mount -t devpts devpts /dev/pts; }
chain_success                        :cmd_spawn          :quiet:/usr/bin/pkill -f "^/usr/bin/tcpsvd -E 0.0.0.0 1023" || true && exec /usr/bin/tcpsvd -E 0.0.0.0 1023 /usr/sbin/telnetd -i -l /bin/login
chain_success                        :dbg_toast          :Started Telnet server on port 1023.
chain_always : nickel_setting : enable : force_wifi

Try something like this:

menu_item:main:Telnet:cmd_output:500:quiet:/usr/bin/pkill -f "^/usr/bin/tcpsvd -E 0.0.0.0 1023"
  chain_success:skip:10
    chain_failure:cmd_spawn:quiet:/bin/mount -t devpts | /bin/grep -q /dev/pts || { /bin/mkdir -p /dev/pts && /bin/mount -t devpts devpts /dev/pts; }
    chain_success:cmd_spawn:quiet:exec /usr/bin/tcpsvd -E 0.0.0.0 1023 /usr/sbin/telnetd -i -l /bin/login
    chain_success:skip:2
      chain_failure:dbg_toast:Error starting Telnet server on port 1023
    chain_always:skip:4
      chain_success:dbg_toast:Started Telnet server on port 1023
      chain_always:nickel_setting:enable:force_wifi
      chain_always:nickel_wifi:disable
      chain_always:nickel_wifi:autoconnect
  chain_always:skip:4
    chain_success:dbg_toast:Stopped Telnet server on port 1023
    chain_always:nickel_setting:disable:force_wifi
    chain_always:nickel_wifi:disable
    chain_always:nickel_wifi:enable

If you're confused by the skips, they're basically if/else, and they're implemented that way so execution is always guaranteed to move forward for stability (fun fact: it was inspired by libpam auth stacks).

I haven't tested this, and I don't know if the wifi toggle (to apply the force_wifi setting) is too fast for Nickel to pick up.

[Cootey]

Originally Posted by geek1011

Try something like this:

menu_item:main:Telnet:cmd_output:500:quiet:/usr/bin/pkill -f "^/usr/bin/tcpsvd -E 0.0.0.0 1023"
  chain_success:skip:10
    chain_failure:cmd_spawn:quiet:/bin/mount -t devpts | /bin/grep -q /dev/pts || { /bin/mkdir -p /dev/pts && /bin/mount -t devpts devpts /dev/pts; }
    chain_success:cmd_spawn:quiet:exec /usr/bin/tcpsvd -E 0.0.0.0 1023 /usr/sbin/telnetd -i -l /bin/login
    chain_success:skip:2
      chain_failure:dbg_toast:Error starting Telnet server on port 1023
    chain_always:skip:4
      chain_success:dbg_toast:Started Telnet server on port 1023
      chain_always:nickel_setting:enable:force_wifi
      chain_always:nickel_wifi:disable
      chain_always:nickel_wifi:autoconnect
  chain_always:skip:4
    chain_success:dbg_toast:Stopped Telnet server on port 1023
    chain_always:nickel_setting:disable:force_wifi
    chain_always:nickel_wifi:disable
    chain_always:nickel_wifi:enable

If you're confused by the skips, they're basically if/else, and they're implemented that way so execution is always guaranteed to move forward for stability (fun fact: it was inspired by libpam auth stacks).

I haven't tested this, and I don't know if the wifi toggle (to apply the force_wifi setting) is too fast for Nickel to pick up.

Fantastic! Thank you for working that up. I've got an all day event today on the books already, but I know what I'll be playing with later tonight. I'll let you know how it goes.

(Also, I appreciate the extra code to study. It'll help me understand your tool better. )

[javl]

Sometimes when I'm reading in bed I'm in a nice position and don't want to move my hand up to my Kobo Clara to touch the screen for a page turn (I know, lazy) so I've added a physical button. I'm using Nickelmenu to start/stop a script that enables this button to work. Problem is this scrips seems to pause after a few seconds/minutes. I think I read somewhere Nickel will pause any background process, but I can't seem to find where this comment was posted. Touching the screen unpauses the script, making the button work again for a few seconds, but this kinda defeats the purpose of the button
Does anyone know if it's possible to prevent nickel from pausing my script?

The line in nickelmenu is something like

:500:quiet /bin/sh /myscript.sh &

Oh and a quick second question: what does the :500 in nickelmenu commands do? It is used in the examples and some lines don't seem to work without it, but it doesn't seem to be explained anywhere?

[NiLuJe]

Yeah, that's not going to work.

Hard to say without knowing exactly what you stuff does, but you'd essentially have to trip *actual* hardware bits flagged as wakeup sources (and that'd most likely require true hardware hackery, or possibly custom kernel trickery to flag more stuff as wakeup?; but most of this is out of my wheelhouse).

Sidebar: That NM snippet is incomplete, the timeout values *are* documentend, and you don't need to explicitly background the script unless you're doing it wrong (i.e., cmd_output instead of cmd_spawn).

[javl]

Currently how this works is I have a Raspberry Pi Pico hooked up to the serial port on the Clara. Pressing the button closes the circuit between the port's VCC and the Pico, starting the Pico (so it doesn't use any power until you press the button). On boot the Pico sends out a single serial signal. A script checks the serial port and triggers a fake tap on the screen when it detects this signal.

Maybe I should explore my second option: when you plug in your USB cable it gets detected even when in this idle state, right? So I was thinking of hooking up a switch to a small USB powerbank and hooking my script into this power detection. I'm just not sure these short bursts of power (like a second every time you press the button) won't damage anything. Also, the USB plug seems to be a fragile point (but I could solder to the PCB instead).

Edit: ahh I see, the 500 is a 500ms delay. I was just looking for '500' in the docs. Didn't occur to me it was one of the regular arguments, sorry.