Forma How can I make my Forma auto power off after 24 hours of no taps or button presses?

[Frenzie]

Originally Posted by davidfor

I'm not sure what you are looking for. From memory, the syslog will show the timer being set when the device sleeps.

What do you mean by the syslog? A particular logfile Nickel writes to?

I thought it was impossible to schedule a wake-up on Kobo. If Nickel is indeed doing so in some wacky non-standard way, we want to know how.

[davidfor]

Originally Posted by Frenzie

What do you mean by the syslog? A particular logfile Nickel writes to?

I mean syslog. You can enable developer mode which will enable logging within nickel and other elements. This is written to syslog and written to disk at particular times.

I thought it was impossible to schedule a wake-up on Kobo. If Nickel is indeed doing so in some wacky non-standard way, we want to know how.

As this conversation started from a comment about scheduling a wake-up to do a sync, then if it is obviously possible to schedule a wake-on on the Kobo. How it is done, I have no idea, but, I doubt it is a "wacky non-standard way".

[baskerville]

Originally Posted by Frenzie

I thought it was impossible to schedule a wake-up on Kobo.

I can do that, on the Glo HD, by writing a Unix Epoch to /sys/class/rtc/rtc0/wakealarm.

[Frenzie]

Originally Posted by davidfor

As this conversation started from a comment about scheduling a wake-up to do a sync, then if it is obviously possible to schedule a wake-on on the Kobo. How it is done, I have no idea, but, I doubt it is a "wacky non-standard way".

I specified precisely why I didn't think it was possible here, so "obviously" the past tense was referring to the time before the beginning of the conversation.

My H2O has a wacky non-standard implementation of the Linux touch protocol, and the framebuffer is wacky too. This is true of many Kobos to some degree. If the H2O has a method to schedule wake-ups, it's not one specified by the Linux kernel docs. It's therefore non-standard by definition. Whether it's wacky is in the eye of the beholder, but as long as the standard methods aren't practically unusable even a superior non-standard implementation is wacky by default.

Originally Posted by baskerville

I can do that, on the Glo HD, by writing a Unix Epoch to /sys/class/rtc/rtc0/wakealarm.

Not on H2O, but it's interesting to know that it's not just 2013-era devices running older firmware on which that works.

[NiLuJe]

The Glo HD is a generation newer than the H2O (MK.6 vs. Mk. 5). If comparing my Forma to my H2O has taught me anything it's basically that everything was terrible until Mk. 6, so this doesn't surprise me too much .

[Frenzie]

Incidentally, that's the kind of thing I meant when I asked if this "indeed happens on all Kobos?" As stated in the linked references I was well aware that it was possible on the Kobo Touch, for example.

Edit: I just updated from 4.5 to 4.15 to see if there was anything new in the Linux kernel. There wasn't, at least not in this regard, but I do notice the wording changed from background sync to automatic sync.

Edit 2: also also, here's an example of a customized Kobo kernel without wacky behavior. Concretely, it sends EV_SYN so the touch events actually work how they should, it doesn't have a wonky framebuffer, and it supports multitouch because the hardware does.

[Frenzie]

Good news, I figured it out. The Kobo Aura H2O wakes up at the time of the alarm set through a relevant ioctl RTC_WKALM_SET call.

You can test this, for example, by using:

rtcwake -m on -s 300

And then suspending.

The key is that if rtcwake tries to perform a suspend-related action it detects that it can't, but if you just set the alarm the device will wake up from suspend at the specified time.

So I'm going to go with likely standard, but still kind of weird? Because the /sys/class/rtc/rtc0/wakealarm method is just a convenient way to do the same thing without having to compile a program.

[Lucas Malor]

I continue to think it's not difficult. You have simply to check if the device is in sleeping mode, and if it continues to be in that state for more than 1 day, you do shutdown, poweroff or every other command that Kobo ships. This will work if Kobo does not send STOP signal to all background tasks when it goes in sleep mode (I don't think so). It's basically something like this:

start_time=$(date +%s)

while true; do
    sleep 3 # or whatever you want. 10? Write 10

    # there should be a way to check if the device is in sleeping mode
    device_is_sleeping=boh 

    if [ $device_is_sleeping -eq 0 ] ; then
        start_time=$(date +%s)
    else
        current_time=$(date +%s)
        elapsed_time = $(echo "$current_time - $start_time | bc)

        if [ $elapsed_time -ge 86400 ] ; then
            poweroff
        fi
    fi
done

I remember there's a way to check if Kobo is in sleeping mode. Probably `nickel` process is in stopped state, but also other third party programs stops nickel.

Alternatively, there's /etc/pm/sleep.d . If Kobo has this folder and it works, you can follow this SO answer.

[NiLuJe]

Except when a device is in suspend... it's in suspend. You can't interact with it via software. For all intents and purposes, it's dead to the (user-space) OS.

Hence the need to setup a *hardware* wakeup via rtc (which will in turn wake the kernel up).

[Lucas Malor]

Originally Posted by NiLuJe

But the point still stands even if you replace it with something they do.

halt does not do a shutdown...

[Lucas Malor]

Originally Posted by NiLuJe

Except when a device is in suspend... it's in suspend. You can't interact with it via software. For all intents and purposes, it's dead to the (user-space) OS.

Hence the need to setup a *hardware* wakeup via rtc (which will in turn wake the kernel up).

Have you tried it? Because I remember I wrote a similar script and it seems to me it worked even if Kobo was in sleeping mode.

I don't think Kobo do a real suspend mode. It probably shows the sleep image and then send a STOP signal to nickel.

[Frenzie]

Apologies for the tautology, but when you're sleeping you're sleeping. If a script were running it wouldn't be sleeping.

You need to schedule a wakeup in x time to shutdown. That's precisely what Nickel does, only for some absurd reason they don't include relevant values. I don't know if memory is bad enough of a concern to use 8-bit here in the first place, but you can just apply those 8-bits to hours and presto, you've got yourself a relevant realm of options at your disposal.

What you want is for the device to shutdown completely to preserve battery if you should let it sit for a few days. About 3-7 days probably makes the most sense as a default, although personally I'd go for something closer to two weeks.

[Lucas Malor]

Anyway, if there's a real suspend mode, so it should exists an /etc/pm/sleep.d . You have to learn to read the entire posts, Niluge

[Lucas Malor]

Originally Posted by Frenzie

Apologies for the tautology, but when you're sleeping you're sleeping. If a script were running it wouldn't be sleeping. .

Frenzie, you didn't know what is a syslog and now you are a Linux expert?

Please, try. Do a stupid script that append to a file the current date every X seconds, put Kobo in sleep mode, resume it after a while and see in the file if there's a gap in data. If so, you have to use /etc/pm/sleep.d, if the dir exists.

[pazos]

Originally Posted by Lucas Malor

Frenzie, you didn't know what is a syslog and now you are a Linux expert?

Lol!

Lucas Malor, this thread has some good anwsers to specific questions. I'm sure that everybody can learn from it. Even you can join the fun too if you wish.