Clara Display time when reading

[NiLuJe]

@desterly: That does indeed sound simpler . @BloodRagg had a PoC that parsed *touch* events in shell over here .

EDIT: Just saw your second post . I linked to evemu/evtest binaries at the end of this post, FWIW .

[desterly]

Originally Posted by NiLuJe

EDIT: Just saw your second post . I linked to evemu/evtest binaries at the end of this post, FWIW .

I started with yours but that version doesn't have the query functionality I don't think... either that or the "parameter" options just don't show.. besides, I needed to test my cross compile environment

I haven't worked with scripts in a LOOOOONG time so I'm sure there is a more efficient way of doing all this but it works as a POC

[NiLuJe]

@desterly: That's definitely a good reason in my book ;D.

(It does, though ;p)

./evtest: unrecognized option '--help'
USAGE:
 Capture mode:
   evtest [--grab] /dev/input/eventX
     --grab  grab the device for exclusive access

 Query mode: (check exit code)
   evtest --query /dev/input/eventX <type> <value>

<type> is one of: EV_KEY, EV_SW, EV_LED, EV_SND
<value> can either be a numerical value, or the textual name of the
key/switch/LED/sound being queried (e.g. SW_DOCK).

[frostschutz]

OK, so... I have two H2O's. The touch loop issue yesterday? I can only reproduce it on one of them.
That's with switching their internal SD cards out so there is no difference in software.

The H2O with the issue is the one I bought with broken display off ebay and performed a display replacement on.

So, uh... stray electrons or something. Infested with nargles. And fbink makes them wander. I really haven't got the foggiest idea. Weirdest issue ever.

I'll see what I can do for ... working around this freak issue anyway, and handling keycodes as it seems unavoidable.

Sorry for the inconvenience & thanks everyone for your patience.

[desterly]

As ugly as it is, the test update/hack I have on my device seems to work. After about 8hrs of "sleeping", my Forma went from 67% battery to 66% battery.

@frostschultz - I might be missing it somewhere too but in the calls, I can't see where the timeout call's return value is actually used. No matter what it returned, the fbInk update was still called. Wrapping it in an check resolved that though.

[frostschutz]

Originally Posted by desterly

@frostschultz - I might be missing it somewhere too but in the calls, I can't see where the timeout call's return value is actually used.

It's used in the {debug} version I uploaded one or two pages earlier.

But yeah, that function originated from my FlashCard mod. For MiniClock, whether it timed out after 60 seconds (update interval), or really touched the display, that didn't matter... not before adding button support anyway.

I probably won't have time to work on this anymore today but I'll try to get an updated version out soonish

[desterly]

Originally Posted by frostschutz

It's used in the {debug} version I uploaded one or two pages earlier.

But yeah, that function originated from my FlashCard mod. For MiniClock, whether it timed out after 60 seconds (update interval), or really touched the display, that didn't matter... not before adding button support anyway.

I probably won't have time to work on this anymore today but I'll try to get an updated version out soonish

Well that makes me feel better... I know I'm rusty but I was starting to question myself.

What I was somewhat thinking of doing here was creating a new bin based off evtest that excepts an input device and a list of KEY_CODES, waits for an event input then returns true/false if it was one that it should have been listening for...

That would do a few things I could see:
1) KEY_CODES could be set as a config option (in case they are different by device and/or someone only wants to refresh when they page forward, not back)

2) allow for a single call replacing the read / evtest call with just one.

3) give me something to do to make it till 5:00 on a Friday when I can go home

This is somewhat what the query mode does currently but w/ that, it makes the call and returns (no wait) which is why in my test I had to leave in the read to actually wait for an event.

[PeterT]

I wonder if this discussion belongs in the Developer subforum?

Sent from my moto g(7) power using Tapatalk

[NiLuJe]

@frostschutz: Gremlins! .

@desterly: I'd then be very tempted to just daemonize and do most of this in C (or, hell, Lua) to go through the FBInk API and avoid the overhead of spamming ioctls & I/O to read fonts over and over again that spam spawning the CLI tool incurs... ;p.

[desterly]

Originally Posted by NiLuJe

@desterly: I'd then be very tempted to just daemonize and do most of this in C (or, hell, Lua) to go through the FBInk API and avoid the overhead of spamming ioctls & I/O to read fonts over and over again that spamming spawning the CLI tool incurs... ;p.

That's probably where it end up.... I just don't like to set myself up w/ goals for minimal available time..

Better to set a low goal and overachieve and feel accomplished at the end

That and it seems kind of rude to say "Hey I found a solution to the next step by completely rewriting what you did and taking another approach"

[frostschutz]

Originally Posted by desterly

That and it seems kind of rude to say "Hey I found a solution to the next step by completely rewriting what you did and taking another approach"

Not at all... if you do it better then it means less work for me.

Otherwise I'll have customizable / selective event system... uh, maybe Sunday or Monday. If not, remind me.

[jamalau]

Hello, I have the same issue, on my Forma, without Sleepcover, i will waiting for the fix!
@frostschutz great Job, Thank you!

Gesendet von meinem SM-T835 mit Tapatalk

[poczynek]

Originally Posted by desterly

I'll test the battery tonight and report back

Any update on how the battery test went with this test version?

Thanks guys for all your help on looking at this too.

[desterly]

Originally Posted by poczynek

Any update on how the battery test went with this test version?

Thanks guys for all your help on looking at this too.

Battery test went good... see https://www.mobileread.com/forums/sh...&postcount=215

I haven't had much time to actually do anything past that though.

[frostschutz]

This is an experimental version.

miniclock.cfg changes:

#
# To debug, set to 1 (will print event parser)
#
debug=0

#
# whitelist of accepted events that should update miniclock
# ABS:MT_POSITION_X/Y: touchscreen coordinates
# KEY:F23/F24: forma forward backward buttons (to be confirmed)
# KEY:POWER: going into standby manually
#
whitelist=ABS:MT_POSITION_X ABS:MT_POSITION_Y KEY:F23 KEY:F24 KEY:POWER

#
# cooldown num time
#
# after receiving num unrecognized events in a row,
# stop listening to all input for <time> seconds.
# (helps avoid power consumption during standby)
# 
cooldown=3 30

Set debug=1 in the config file and the events will be printed on screen. This is useful to determine new values for the whitelist. (I wasn't sure about Forma page button event as I don't have a Forma... the F23/F24 I found online somewhere, not necessarily correct. I also don't know if all touchscreens use the MT_POSITION_X event or not.).

If non-whitelisted events keep coming in, MiniClock will stop listening to the input devices for a time (cooldown). This is in hopes of avoiding drain when something keeps sending odd events. Not sure if this works.

Add "{debug}" to the date format string and cooldown itself will update the clock, so you see it happens at all. Otherwise {debug} will show which event caused the update.

Please let me know if it works for you...