Clara HD Display time when reading

[NiLuJe]

And while I'm there, here's how the various fonts look, in this context .

[jackie_w]

Originally Posted by NiLuJe

... * You can get a "transparent" background by adding a -O to the command.

Originally Posted by Terisa de morgan

Forma I have, shell access no (and I'm not very ready for tinkering in that side). Ah! And thanks for the -O command

OK, what's your cunning secret I cannot get either the -O or -o option to work satisfactorily in white-on-black Nightmode. I've tried all sorts of tweaks to the fbink statement in miniclock.sh without success (including removing the -B parameter). Whatever combo I've tried ends up with a white background, not a transparent one.

This is the default fbink statement for Miniclock:

    fbink -X "$cfg_offset_x" -Y "$cfg_offset_y" -F "$cfg_font" -S "$cfg_size" \
          -C "$cfg_fg_color" -B "$cfg_bg_color" \
          "$(date +"$cfg_format")"

What should it be to get optimal results in both black-on-white and white-on-black modes? In case it's relevant, I set the config file's fg_color=GRAY7 so that the HH:MM would be equally visibly muted in both modes.

BTW:

• using the -O option has the minor drawback that, when the minutes value changes, the new value is overlaid on the old value until the next screen touch tidies it up.
  
• using the -o option just gives me a white background rectangle with no HH:MM display.

[MGlitch]

Just checking (and waiting for a response to jackie_w's question) but I presume you need to have the footer displayed for this hack to work?

[NiLuJe]

@jackie_w:

* Good point, the fact that it doesn't draw a background *at all* means that this sort of thing can indeed happen, yeah .

* That may be a side-effect of how night-mode actually inverts the screen. With a software nightmode, it would work, but if it relies on the controller's inversion (which I *think* the latest versions do), I indeed have no idea how it might work, but probably not well ;p. And if the hack somehow manages to hook into fbink's own refresh calls, that's one more layer of unknown .

(But given the fact that you mention a white rectangle, I'm guessing the hack doesn't touch fbink's calls, and that rectangle is the refresh region itself, not getting inverted because fbink never does that).


That's what you get for weird 5AM ideas, I guess, sorry ;p.

[frostschutz]

Originally Posted by MGlitch

I presume you need to have the footer displayed for this hack to work?

This hack doesn't care at all. You touch the screen, it displays the clock.

It does that 3 times (repeats) with 1 second in between (delay), configurable to some extent...

Why repeat the call? I can register touchscreen activity but I don't know how long nickel takes to flip the page after that, and also you could be flipping two pages in quick succession, and in the old version of the hack, that would cause the clock to not show up in the end...

Anyway this was meant as a quick and dirty fix, suprised how much attention this is getting to be honest

[NiLuJe]

@frostschutz: Don't be, I still have a similar quick'n dirty (and awfully inefficient) hack for Kindle lying around, and it was born the exact same way: on a bored night over 4 years ago after reading one random request ;D.

[jackie_w]

@NiLuJe,
OK. I thought it was just me being dumb

Originally Posted by frostschutz

Anyway this was meant as a quick and dirty fix, suprised how much attention this is getting to be honest

Is I.T. your proper day job, too? If so, I would have thought that you would be familiar with the concept that the user's interest is inversely proportional to the blood, sweat & tears you shed

[Terisa de morgan]

Originally Posted by jackie_w

Is I.T. your proper day job, too? If so, I would have thought that you would be familiar with the concept that the user's interest is inversely proportional to the blood, sweat & tears you shed

I totally agree

[Terisa de morgan]

Originally Posted by jackie_w

OK, what's your cunning secret I cannot get either the -O or -o option to work satisfactorily in white-on-black Nightmode.

My secret? I don't use nightmode

[jackie_w]

Originally Posted by Terisa de morgan

My secret? I don't use nightmode

Well, that's cheating!

[frostschutz]

...

there's a chance the wrong time will be displayed

I have no idea why or how this happens, but somehow the miniclock process starts living in its own time zone

someone please explain this to me

# date
Sun Oct 28 00:18:59 CEST 2018
^^^^^^^^^^^^^^^^^^^^
# strace -ff -p $(pidof miniclock.sh)
./strace: Process 765 attached
restart_syscall(<... resuming interrupted restart_syscall ...>) = 1
read(0, 0xa6d28, 1)                     = -1 EINVAL (Invalid argument)
dup2(11, 0)                             = 0
close(11)                               = 0
[...]
[pid 13229] stat64("/sbin/date", 0x7e98db70) = -1 ENOENT (No such file or directory)
[pid 13229] stat64("/usr/sbin/date", 0x7e98db70) = -1 ENOENT (No such file or directory)
[pid 13229] stat64("/bin/date", {st_mode=S_IFREG|0755, st_size=532224, ...}) = 0
[pid 13229] execve("/bin/date", ["date", "+%a %b %d %H:%m"], [/* 13 vars */]) = 0
[pid 13229] brk(NULL)                   = 0xa4000
[pid 13229] uname({sysname="Linux", nodename="(none)", ...}) = 0
[...]
[pid 13229] gettimeofday({tv_sec=1540678741, tv_usec=421127}, NULL) = 0
[pid 13229] brk(NULL)                   = 0xa4000
[pid 13229] brk(0xc5000)                = 0xc5000
[pid 13229] open("/etc/localtime", O_RDONLY|O_CLOEXEC) = 3
[pid 13229] fcntl64(3, F_GETFD)         = 0x1 (flags FD_CLOEXEC)
[pid 13229] fstat64(3, {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
[pid 13229] fstat64(3, {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
[pid 13229] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aac4000
[pid 13229] read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\10\0\0\0\0"..., 1024) = 1024
[pid 13229] _llseek(3, 1257, [2281], SEEK_CUR) = 0
[pid 13229] read(3, "\nCET-1CEST,M3.5.0,M10.5.0/3\n", 1024) = 28
[pid 13229] close(3)                    = 0
[pid 13229] munmap(0x2aac4000, 4096)    = 0
[pid 13229] fstat64(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
[pid 13229] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aac4000
[pid 13229] write(1, "Sun Oct 28 00:10\n", 17) = 17
[pid 13229] exit_group(0)               = ?
[pid 13229] +++ exited with 0 +++
<... read resumed> "Sun Oct 28 00:10\n", 128) = 17
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[...]
[pid 13230] execve("/usr/local/MiniClock/fbink", ["fbink", "-X", "2000", "-Y", "2000", "-F", "IBM", "-S", "0", "-C", "BLACK", "-B", "WHITE", "Sun Oct 28 00:10"], [/* 13 vars */]) = 0

okay today is daylight saving clock change day, that might cause weird things, but... doesn't make a lick of sense to me right now. it's stuck on 00:10 forever now, but shell on the same device displays time correct


edit: issue persists after reboot and even poweroff, so I'll put this down to moon radiation then

edit: it's because I had %m instead of %M in the format string silly me

[NiLuJe]

That's... interesting .

I assume gettimeofday returns the exact same tv each time?

Could this be another weird quirk of udev's spawn restrictions?

[frostschutz]

it flipped from 00:10 to 01:10 (before it actually was 01:10) and now it's stuck on that

guess it's somehow related to daylight saving transition but I don't understand, how it's possible for this to affect a background shell script, but not the interactive shell.

timing seems to be still working fine otherwise

[jcn363]

Just to inform.
My A1 has power off last night (perhaps due to daylight saving transition?).
Situation:
Battery: 80%
go to sleep: 5 mins
power off: never
After power on all seems as usual.
Good luck.

[Terisa de morgan]

My Clara is sleeping (as it should, inside the sleepcover). No issue with time display or power off.