Clara HD Display time when reading

[frostschutz]

I don't understand what's going on at all. Trigger the magnet even once and nickel is awake all the time, and miniclock sees wild touchscreen events all the time.

I thought perhaps this could be a standby side effect. It would make sense to power down the touchscreen during standby. Maybe some odd inputs happen when it's powered back up (waking from the magnet). And then it's in a cycle it doesn't get out of. But that's just a theory, I have no way to confirm.

Why doesn't it stay asleep? It works fine as long as no magnet is involved. Use a magnet and it's crazy, until you wake it up for good and wait a moment and then go back to standby.

This is either a bug in Kobo firmware, or a very very odd interaction with addons, and I have no idea what I'm doing wrong (if it's me at all). In general magnet / sleepcover + battery drain reports aren't anything new, maybe related, maybe not.

[NiLuJe]

@frostschutz: That's... strange on a H2O, but not so much on the Forma, since it added support for repeat keycode events, and the SleepCover *does* repeat, which is mightily stupid.

At least the insanity stops when the device actually suspends, but I don't know how long that takes for Nickel .

And, of course, if you wake it up before that, it never actually goes to sleep => boom.

[NiLuJe]

AFAIK, the hall sensor is *always* somewhere on top of the screen, and not the bezel (another weird design choice). So, on devices with an IR grid, the contact point will always disrupt the beam (especially when you test with a fridge magnet ^^) => touchscreen events.

This *might* require ignoring touch events between SleepCover [1 <-> 0] events, which is going to be mightily fun...

(IIRC, this is what we do in KOReader, with an extra "go back to sleep" command if something weird happens, which, believe me, is nearly always the case with those stupid SleepCovers).

[frostschutz]

for testing I use a refrigerator magnet on the back of the device, far from the touchscreen.

and I was able to narrow the mystery down some:

- after input event, miniclock calls fbink to update the clock on the screen

- something fbink does wakes nickel

- somehow somewhere that triggers a touch event

- after input event, miniclock calls fbink to update the clock on the screen

...and back to top, the cycle never ends.

If I replace fbink with a wrapper that logs the call, but doesn't actually call fbink, the cycle breaks.

If I re-add the fbink call to the wrapper, the cycle resumes.

So... mysterious side effects. How fbink wakes nickel and how that translates into stray touch events that in turn wake miniclock, to call fbink in turn... that's still not clear to me.

And I'm back to the same issue I have with the screensaver addon of mine... I have no way to reliably detect that the device is currently supposed to be in standby mode. If I could detect it I'd just stop calling fbink during standby.

[NiLuJe]

The mxcfb refresh ioctl is likely the cause of the wakeup, I can't see anything else having any potential effect (EDIT: And I don't see anything unexpected in a strace run, either). Unless disk I/O counts, somehow, but that only happens with TTF/OT fonts (EDIT: Not really, device ID requires disk I/O, too).

At least, I can see that waking the kernel. Not quite sure how that could ever translate to a touch event, though :?.

EDIT: You can test that theory by enabling --norefresh.

If you start decoding the input events, having a specific idea of exactly *which* kind of event that is might be helpful .

/sys/power/state-extended *should* return 1 right before a suspend, but I don't rightly remember how Nickel times all of this, so this might not actually be usable.

[NiLuJe]

Useless reply just to point out various new edits in my previous answer .

[frostschutz]

raw data of weird touch events

00000000  83 b7 30 5d a1 8e 08 00  01 00 34 01 00 00 00 20  |..0]......4.... |
00000010  83 b7 30 5d ac 8e 08 00  00 00 00 00 00 00 00 00  |..0]............|
00000020
8165.68 8082.91
Thu Jul 18 20:16:35 CEST 2019
00000000  87 b7 30 5d 6a 9e 08 00  01 00 34 01 00 00 00 20  |..0]j.....4.... |
00000010  87 b7 30 5d 75 9e 08 00  00 00 00 00 00 00 00 00  |..0]u...........|
00000020
8169.69 8086.81
Thu Jul 18 20:16:39 CEST 2019
00000000  8b b7 30 5d 6e 98 08 00  01 00 34 01 00 00 00 20  |..0]n.....4.... |
00000010  8b b7 30 5d 7b 98 08 00  00 00 00 00 00 00 00 00  |..0]{...........|
00000020
8173.69 8090.71
Thu Jul 18 20:16:43 CEST 2019
00000000  8f b7 30 5d be 97 08 00  01 00 34 01 00 00 00 20  |..0]......4.... |
00000010  8f b7 30 5d c7 97 08 00  00 00 00 00 00 00 00 00  |..0]............|
00000020
8177.69 8094.62
Thu Jul 18 20:16:47 CEST 2019
00000000  93 b7 30 5d 0b 8d 08 00  01 00 34 01 00 00 00 20  |..0]......4.... |
00000010  93 b7 30 5d 14 8d 08 00  00 00 00 00 00 00 00 00  |..0]............|
00000020
8181.68 8098.52
Thu Jul 18 20:16:51 CEST 2019

I'll add a check in an attempt to ignore those bogus events.

How come simple things turn out so difficult. Haha.

[Terisa de morgan]

Originally Posted by frostschutz

using the latest version from yesterday?

No. SW engineer here --> If it works, don't touch, and I don't need buttons.

[NiLuJe]

Err, EV_KEY : KEY_DOT, from a touchscreen? o_O

(TBC, in a hurry right now ;p).

[poczynek]

Sorry just to confirm mine drained overnight. Also I do not use a magnet cover.

Sent from my SM-G970F using Tapatalk

[jackie_w]

It looks like the button battery drain investigation has progressed past any of my observations today being useful. So I'll just summarise it by saying:

• whether the Forma was in or out of the magnetic sleep case or whether the auto sleep/wake setting was on/off I had a reasonable battery drain rate of about 1%/hour whilst I was actually reading.
• Once the Forma was put into long term standby (by closing the sleep case cover) then the battery drained much faster - about 5-6%/hour.

[NiLuJe]

For future reference: the cover setting is irrelevant here, we get the hardware events regardless .

On the Forma, the SleepCover *will* send KEY_REPEAT events (every 80ms after a 400ms delay), so, that won't help, and while fairly stupid, that's at least not mysterious .

EDIT: See this KO issue for more details . And a bonus picture in case you were looking for the hall sensor position ;p.

Now, regarding those weird touch events on the H2O, I'm a bit stumped.
That *looks* like an EV_KEY -> KEY_DOT

E: 1.412001 0004 0004 458807    # EV_MSC / MSC_SCAN             458807
E: 1.412001 0001 0034 0001      # EV_KEY / KEY_DOT              1
E: 1.412001 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +1412ms
:E: 1.468005 0004 0004 458807   # EV_MSC / MSC_SCAN             458807
E: 1.468005 0001 0034 0000      # EV_KEY / KEY_DOT              0
E: 1.468005 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +56ms

(That's from my actual keyboard, hence the stray : (AZERTY layout here) ;p)

Except that doesn't make any sense for a Touch input device, and that final 0x20 byte doesn't make sense either.

The only other event with a 0x34 code is ABS_MT_ORIENTATION, but that's an EV_ABS, and should never happen on those devices.

It is the final link in the event chain on a Forma, though, but that looks like this:

E: 41.149809 0003 0034 0125     # EV_ABS / ABS_MT_ORIENTATION   125
E: 41.149809 0000 0002 0000     # ++++++++++++ SYN_MT_REPORT (0) ++++++++++
E: 41.149809 0000 0000 0000     # ------------ SYN_REPORT (0) ---------- +11ms

(That's output from evemu-record, of which I have a Kobo build here).

[poczynek]

Sorry typo!

[desterly]

I would think that the simplest thing might be to read the keycode value and if it's 193 or 194 then allow updating.... assuming that it is the fbInk event that is causing the wakeup

might even be able to read it with sed (i really need to learn sed one day) but worst case, a small bin that simply outputs the code value from the event.

[desterly]

I made a few modifications on mine to see what would happen. This is specific for the forma and buttons (which is what I use)

1) I compiled an updated evtest that has query functionality and dropped it on the device (from here: git://anongit.freedesktop.org/evtest)

2) updated timout_touch() as follows

timeout_touch() {
    local touched="not"
    read -t "$1" touched < "$2"
    /mnt/onboard/.stuff/kobo-evtest/evtest --query /dev/input/event0 EV_KEY 193
    eventkey=$?
    if [ $eventkey -eq 0 ];
    then
        /mnt/onboard/.stuff/kobo-evtest/evtest --query /dev/input/event0 EV_KEY 194
       eventkey=$?
    fi
    [ "$eventkey" = "10" ]
}

3) modified the button check by adding a test to the return of timeout_touch:

           timeout_touch $((1 + $cfg_update - ( ($(date +%s)+$cfg_delta) % $cfg_update))) /dev/input/event0
           if [ $? -eq 0 ];
           then
               for i in $cfg_delay
               do
                   sleep $i
                   update
               done
           fi

With these modifications, fbink is ONLY called if the up/down button (193/194) are the KEY_CODES called to event0.

It's still calling timeout_touch constantly with the other KEY_CODE values but at least it isn't calling fbink anymore.

I'll test the battery tonight and report back