Kute File Monitor: A smarter file-trigger based launcher

[NiLuJe]

@frostschultz:

Indeed, thanks for the pointer .

┌─(ROOT@(none):pts/0)──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────(/mnt/onboard/.adds)─┐
└─(0.00:54%:16:46:100%:#)── strings /usr/local/Kobo/libnickel.so.1.0.0 | ag /dev/input                                                                                                                                                                      ──(Fri, May 20)─┘
/dev/input/event1
/dev/input/event2
/dev/input/event0:keymap=keys/device.qmap:grab=1:repeat-rate=0:repeat-delay=0

The touch input is left alone, it only grabs the power button over here.

As for sickel, I just SIGSTOP'ed the lot of 'em ;D. That might in turn mess wifi up, either for KOReader or Nickel, but, meh, good enough for quickly testing stuff.

[Lucas Malor]

What if you trigger a fake power button event?

[NiLuJe]

@Lucas Malor: Meaning what, exactly? I'm not aware of such a built-in possibility on Kobos (unlike on Kindles).

And in any case, we'd still need a way to actually trigger that. Since we're out of physical input devices, that means an extra UI element somewhere.

[Lucas Malor]

Read it here: https://www.mobileread.com/forums/sho...0&postcount=94 I think there's a way to simulate a long power slide too.
I suppose then nickel will fire a busybox shutdown -h now. If you'll disable it, you can shutdown nickel safely.

[NiLuJe]

@Lucas Malor: That's a long-press over here, which means a shutdown (of the *system*).

[Lucas Malor]

Yes, but I suppose it's nickel itself that fires a `busybox poweroff` when the power slice is long-pressed. If you move the `poweroff` executable, wait for nickel death and restore it, nickel will be terminated as intended without OS shutdown.

[NiLuJe]

@Lucas Malor: It wouldn't appear so.

┌─(ROOT@(none):pts/0)───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────(/)─┐
└─(0.33:31%:19:33:96%:#)── strings /usr/local/Kobo/libnickel.so.1.0.0 | grep -e halt -e shutdown -e poweroff                                                                                                                                                ──(Sat, May 21)─┘
_ZN11EventEngine8shutdownEv
_ZN11EventEngine12shutdownSlotEv
shutdownSlot
shutdownSlot

And we have no actual way of knowing if nickel actually gets killed "cleanly" on a long-press anyway, that's an assumption I'm not willing to take for granted.

[pazos]

Originally Posted by NiLuJe

If I ever find some time/motivation, one utility I'd like to do is a simple (i.e., no Qt) tool to print text messages to the framebuffer (for those familiar with it, we have eips on Kindles, and it's damn useful).
For instance, right now, hitting a SQL busy timeout can be a bit mystifying, since there's zero actual feedback besides the action not launching :/.

I did this before on my device using SDL_ttf. I hardcoded screen resolution and text position. Attached a demo video

SDL is broken on kobos because fbcon video driver relies on VT switching, so the binary can't be called directly (it waits forever on VT_WAITACTIVE).

[root@kobo ~]# zcat /proc/config.gz | grep CONFIG_VT
CONFIG_VT=y
# CONFIG_VT_CONSOLE is not set
# CONFIG_VT_HW_CONSOLE_BINDING is not set

Try to do a lsof for any of /dev/tty* and you'll find the same results for each of them.

The only solution I found is run the binary in bg and send a SIGTERM just after that.

#!/bin/sh
SDL_NOMOUSE=1
./fbprint $@ &
pid=$!
sleep 0.3
kill -15 $pid

I wonder if this does the trick for you.

[NiLuJe]

@pazos: That's better than nothing, yeah ;p. I'm all for it, if you're willing to open the code .

[pazos]

Of course !!!

Don't expect good code, BTW

this depends on freetype, SDL & SDL_ttf

I use VeraMono.ttf, but any monospace font will work

[NiLuJe]

@pazos: Thanks .

Don't worry, at the very least that's good motivation and a working example .

[davidfor]

Originally Posted by NiLuJe

@Lucas Malor: It wouldn't appear so.

┌─(ROOT@(none):pts/0)───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────(/)─┐
└─(0.33:31%:19:33:96%:#)── strings /usr/local/Kobo/libnickel.so.1.0.0 | grep -e halt -e shutdown -e poweroff                                                                                                                                                ──(Sat, May 21)─┘
_ZN11EventEngine8shutdownEv
_ZN11EventEngine12shutdownSlotEv
shutdownSlot
shutdownSlot

And we have no actual way of knowing if nickel actually gets killed "cleanly" on a long-press anyway, that's an assumption I'm not willing to take for granted.

Depends on how long the press is. Tap to sleep, hold for a few seconds will initiate a shutdown and nickel will close cleanly. Hold it longer, I usually say 20 seconds but it should be shorter, and it just powers off.

It hasn't been mentioned, but have you enabled the nickel logging? I have the following in my config file:

[DeveloperSettings]
EnableDebugServices=true
EnablePacketDump=true
DebugPM=true
EnableInspector=true

"EnableDebugServices" enables a general log for nickel and writes to a syslog in the users .kobo directory. "DebugPM" enables more debugging writing to dmesg. The "PM" stands for "Power Management".

Edit: I should just add for anyone who sees this and thinks it's a good idea to add these lines. The debug services also enables a telnet service. This tends to block the WiFi from turning off and the device from automatically sleeping. And that runs the battery down a lot faster. I only use these options when I am debugging something.

[NiLuJe]

@davidfor: Now that's interesting, thanks! And might also come in handy to dig into the suspend crap for KOReader...

[pipcat]

Cute tool NiLuJe!

I was looking a way to execute a custom .sh script from Nickel, and I see this can be done with kfmon and a png file. Nice ;-)

So I can download a zip file with patches from Kobo browser, and later press on a .png to process it in a bash script.

But going further, could it be possible to use kfmon to watch for a non-png file ? In this case I want to monitorize if a zip file exists, to process it. For example, something like this:
[watch]
filename = /mnt/onboard/download.php ; Zip file downloaded from pip.cat/khd/kobo
action = /mnt/onboard/.adds/autopatch/process.sh
skip_db_checks = 1

process.sh should unzip file, delete, generate a KoboRoot.tgz in .kobo and restart nickel to process KoboRoot. As if we copied it via usb and disconnect.

Are there other ways to execute a script by request, not at boot time ?
Maybe we can change an unused game to execute a .sh instead of his code ?

[NiLuJe]

@pipcat: Right now, nothing prevents you from watching something other than a PNG file, it's just that we know PNGs create a tile, making them easily user-facing (and the amount of stray OPEN/CLOSE events on those is limited) .

As for your specific idea, you cannot watch for a non-existent file with inotify (and, in kfmon's case, trying to setup a watch for a non-existent file is a fatal error that will cause the daemon to shutdown).

In this case, a simple workaround would be a wrapper script: watch for an always-there tile (i.e., a PNG), which will trigger a script which will then check for the existence of your zip file and process it if need be.

That means user-interaction, though, it won't automagically run when the zip file appears (if that was what you were trying to achieve).