kTimepiece - A clock application for kindle

[kiri87]

Here is a little application I've been working on this weekend. It's just something I wanted on my kindle for a long time. It basically draws a simple clock on screen, and updates it every second/minute.
Most of the code is based on geekmaster's dithermatron, although I admit that I using just a little of the magic that the code offers.
The center of the clock is cleared and the hands are redrawn at each update; the background is drawn from an external file when you start the app.
(After the screensaver kicks in, in no longer gets updated, so it would be a good idea to use ~disableScreensaver to prevent that. ) - not anymore.
The background image location is hardcoded, so you have to put the binary and the .png file on the root folder. (/mnt/us/)
I know it's not very advanced, (it's kinda reinventing the wheel), and there are still things that could improve, but I decided to share this with you.

Update: Added launchpad actions to start/kill clock, and prevent screensaver. Use T S to start and T Q to quit.

TODO:
- Keep track of the pixels drawn in the previous loop, so only those are cleared.
- Flash the central part each hour to remove ghosting.
- Un-hardcode the background image location, so it can be moved to a separate folder.

Enjoy.

[geekmaster]

Cool. I like seeing how people bend the tools I provide.

For unpublished code, I linked the math lib with:

tccmake myprog -lm

but you could do -lm-2.5 instead.

The nice thing about tccmake is that it works on the K5 by binding a naughty library loader script in /usr/lib, where your "tcc" command in the code comments would fail.

Also, beware that this older setpx() will draw inverted colors on a K4 when booted from main, so I would draw a white outline around the black hands, to make them visible in case they were inverted to white hands with black outline. Or... update to the gmlib() code in the newest demos.

Thanks for doing stuff with my code -- it makes it feel a lot less like an unappreciated waste of time when I invest so much time and effort to provide a learning opportunity and tools for others at no charge, and then to see so few downloads of my files. Oh well... Just thanks.

And instead of the sleep(1), which can be up to half a second off, I would use usleep(1000000), which is more accurate, but sleep calls can drift. After a sleep for ALMOST the time you want, you should synchronize to the REAL time provided by the getmsec() function (later in your code). This is how video games keep accurate framerates (sleep almost enough, then busy-wait for accurate clock tick).

[inameiname]

This is pretty cool. Thanks for sharing, and for all who contributed!

I wonder if it would be possible to have it automatically disable the screensaver when it is running. Basically so you don't have to input the ~disable screensaver bit each time. Or maybe there is a way to have it run instead of the screensaver.

As of now, you can probably easily create a Launchpad shortcut that would merely delay the screensaver from running instead of disabling it. I would just write a script that would first change the screensaver timeout (maybe change it to 24 hours or something), using a variant of this script: https://www.mobileread.com/forums/sho...d.php?t=162300, then have it run this clock program, and then when closed, it restores the screensaver timeout to what it was before. However, this is a bit of a workaround, and I am sure there is a much better way to do it.

Also, just to share, since the eInk lets you see the ghosting of where the second hand was in past seconds, I found it interesting that each of the fainted lines aren't uniformly spaced, or exactly the same amount of distance away from one another. Perhaps this reflects what geekmaster was talking about in regards to the delay the time the sleep(1) versus usleep(1000000) does. As such, it might not keep an accurate time as it stands now. But I would have to keep it on this clock for a while to test the accuracy of it.

Finally, would it be possible to be able to put both the kTimepiece program and the *.png files into a separate folder, rather than cluttering up the main directory, such as '/mnt/us/kTimepiece/' or something? I can already place the program into that folder and change the Launchpad shortcut, but the *.png of the clock itself has to be in the main directory.

Regardless, glad to finally get a nice little clock! Thanks.

[geekmaster]

Originally Posted by inameiname

This is pretty cool. Thanks for sharing, and for all who contributed!

I wonder if it would be possible to have it automatically disable the screensaver when it is running. Basically so you don't have to input the ~disable screensaver bit each time. Or maybe there is a way to have it run instead of the screensaver.

As of now, you can probably easily create a Launchpad shortcut that would merely delay the screensaver from running instead of disabling it. I would just write a script that would first change the screensaver timeout (maybe change it to 24 hours or something), using a variant of this script: https://www.mobileread.com/forums/sho...d.php?t=162300, then have it run this clock program, and then when closed, it restores the screensaver timeout to what it was before. However, this is a bit of a workaround, and I am sure there is a much better way to do it.

Also, just to share, since the eInk lets you see the ghosting of where the second hand was in past seconds, I found it interesting that each of the fainted lines aren't uniformly spaced, or exactly the same amount of distance away from one another. Perhaps this reflects what geekmaster was talking about in regards to the delay the time the sleep(1) versus usleep(1000000) does. As such, it might not keep an accurate time as it stands now. But I would have to keep it on this clock for a while to test the accuracy of it.

Finally, would it be possible to be able to put both the kTimepiece program and the *.png files into a separate folder, rather than cluttering up the main directory, such as '/mnt/us/kTimepiece/' or something? I can already place the program into that folder and change the Launchpad shortcut, but the *.png of the clock itself has to be in the main directory.

Regardless, glad to finally get a nice little clock! Thanks.

The getmsec() function calls a system function that actually returns the date and time, but that may not be accurate if your kindle has not been connected to Internet or 3G recently. I just use it to monitor the accurate passage of time, so you could use it that way too. The first time it is called at program startup, it returns value 0; Any call after that is number of milliseconds since program startup, so if you know what time it was when you started, that tells you how many msec since then -- just divide the returned value by 1000 and add to your startup time (seconds). Do not try to keep accurate time with sleep() or usleep() calls. I implemented getmsec() for accurate framerate control, but you can use it to run a clock to. Just do it!

Some of my scripts in the "eink algorithmic art" thread pause the framework and disable screensavers, then resume them at the end. These "Dithermation" programs could use a system() call to do exactly the same thing, but in this case keep the framework running and only stop the screensaver, then restart it at exit.

These programs can run while IN screensaver mode, and in some cases actually run faster that way (not competing with the framework for resources). And if they sleep correctly with very little eink updating (like a clock) they do not eat extra battery. Sleep mode only shows a screensaver image and disables the keyboard -- the kindle basically "sleeps" all the time and the framework only wakes to process events like key presses. That is why the battery can last so long.

[kiri87]

I'm getting the with time() and localtime(). I'm not sure why the getmsec() function call was left in there. Initially I planned to update the clock every minute, so it won't affect the battery too much, thus, using sleep() wouldn't be that bad, even though it might be half a second off.
The angle of each hand is always calculated corectly, but sometimes the seconds line skips a beat (eg: 2 sleep(1)s that return after 1.5 seconds), so that's why sometimes the lines don't appear to be uniformly spaced.
I have updated to the latest gmlib, but it seems that "eips -g ./clockFrame2.png" no longer works. It flashes the image on screen, but after calling gmlib(GMLIB_UPDATE), it's replaced with an image from tmp/wb0. In my case, the last image from the hoser-2.0 demo https://www.mobileread.com/forums/sho...9&postcount=32 was displayed behind the clock.
I'll have to look into the screensaver disabling solution, when I have the time. These are the precious calls, correct?

lipc-set-prop com.lab126.powerd preventScreenSaver 1
killall -stop Xorg cvm # pause framework

killall -cont cvm Xorg # resume framework
lipc-set-prop com.lab126.powerd preventScreenSaver 0

[geekmaster]

Originally Posted by kiri87

I'm getting the with time() and localtime(). I'm not sure why the getmsec() function call was left in there. Initially I planned to update the clock every minute, so it won't affect the battery too much, thus, using sleep() wouldn't be that bad, even though it might be half a second off.
The angle of each hand is always calculated corectly, but sometimes the seconds line skips a beat (eg: 2 sleep(1)s that return after 1.5 seconds), so that's why sometimes the lines don't appear to be uniformly spaced.
I have updated to the latest gmlib, but it seems that "eips -g ./clockFrame2.png" no longer works. It flashes the image on screen, but after calling gmlib(GMLIB_UPDATE), it's replaced with an image from tmp/wb0. In my case, the last image from the hoser-2.0 demo https://www.mobileread.com/forums/sho...9&postcount=32 was displayed behind the clock.
I'll have to look into the screensaver disabling solution, when I have the time. These are the precious calls, correct?

lipc-set-prop com.lab126.powerd preventScreenSaver 1
killall -stop Xorg cvm # pause framework

killall -cont cvm Xorg # resume framework
lipc-set-prop com.lab126.powerd preventScreenSaver 0

In the new gmlib, the *real* framebuffer is /tmp/wb0, so after the "eips -g" call you need to copy each of the 600-byte wide lines from /dev/fb0 to /tmp/wb0. The display updates dither that across, so the result will be dithered. This new method was intended for high-speed animation, and will give you a dithered background.

So, until I add more features to gmlib (partial area dithers, etc.) perhaps you are better served by the old version.

Those calls look right. The Xorg process is only used for the K5(touch), but it does not hurt to try killing a non-existing process. The "lipc" commands control the screensaver, so you can use those. If you want to stop the framework from drawing crap on your clock, you may want to pause it too. But resume it at the end. They keyboard does not work when cvm paused, so you need to process keyboard events your self, either with a call to "waitforkey" (which pauses) or from directly from the input device.

[inameiname]

Originally Posted by geekmaster

The getmsec() function calls a system function that actually returns the date and time, but that may not be accurate if your kindle has not been connected to Internet or 3G recently. I just use it to monitor the accurate passage of time, so you could use it that way too. The first time it is called at program startup, it returns value 0; Any call after that is number of milliseconds since program startup, so if you know what time it was when you started, that tells you how many msec since then -- just divide the returned value by 1000 and add to your startup time (seconds). Do not try to keep accurate time with sleep() or usleep() calls. I implemented getmsec() for accurate framerate control, but you can use it to run a clock to. Just do it!

Some of my scripts in the "eink algorithmic art" thread pause the framework and disable screensavers, then resume them at the end. These "Dithermation" programs could use a system() call to do exactly the same thing, but in this case keep the framework running and only stop the screensaver, then restart it at exit.

These programs can run while IN screensaver mode, and in some cases actually run faster that way (not competing with the framework for resources). And if they sleep correctly with very little eink updating (like a clock) they do not eat extra battery. Sleep mode only shows a screensaver image and disables the keyboard -- the kindle basically "sleeps" all the time and the framework only wakes to process events like key presses. That is why the battery can last so long.

Thanks for all the assistance and info above. I actually hadn't been online in a few days, so maybe it was causing the variance between seconds in the clock program. Unfortunately, I am not extremely familiar with how to change the code so make it more accurate, so while I appreciate the dithermation and way to help it, I think I will just leave it as it is.

And I did notice it can be run in screensaver mode, but it does require a little bit of tweaking to work properly.

[kiri87]

As you may have noticed, I added launchpad actions to start/quit the app, and it _does_ work properly as a screensaver. I didn't touch the code, though. And doing an update every second eats up the battery quite fast.

I'm new to Linux programming. How do I check the the "pressed" state of a key, so I can break out of a for ( ; ; ) loop?

[geekmaster]

Originally Posted by kiri87

As you may have noticed, I added launchpad actions to start/quit the app, and it _does_ work properly as a screensaver. I didn't touch the code, though. And doing an update every second eats up the battery quite fast.

I'm new to Linux programming. How do I check the the "pressed" state of a key, so I can break out of a for ( ; ; ) loop?

The simplest way (which can also be done from a script) is to launch the "waitforkey" program in the background and pipe its output to a temp file. You can either tell it to wait for a specific key and call "ps|grep" (with other parameters) to check for it to quit after it sees the key it is waiting for (default ANY key). Or you can periodically check the output file for a pressed key code. Details were provided in another thread.

A more "correct" way is to process the input device events for the keyboard and/or other devices (like touch screen). I have an unfinished script that does a pretty good job of processing raw binary input device events using hexdump, for both keys and touchscreen.

The nice thing about "waitforkey" is that is returns key codes for other events too, like touchscreen (one or two fingers touching, or touch PLUS home key), and even rotation events are returned as pressed keys by waitforkey. And by the way, even though most input devices are turned off when asleep (screensaver mode), waitforkey returns rotation events while asleep. That way a background program can wake the kindle when it is picked up (and rotated enough to trigger a rotation event).

[brianinmaine]

I am trying to get this working on my touch:
https://www.mobileread.com/forums/sho...d.php?t=176355

It works, kind of, but is has issues. After a few seconds, the menu at the top shows some, and you have to kill it with the power button. Not sure how useful this would be, but it's pretty!

A REALLY cool idea would be to use this as a screensaver (no second hand screen updates?) Still, might be useful.

you have to copy/move the png images in the archive to /mnt/us to make it work.

[twobob]

kterm, skipstone, tar, kindle touch.

using just those i can now confirm it works great sweet!

[twobob]

I keep coming back to this... And thinking... how could this be made to be more solidly useful.. So.. If I think of something really great I'll shove it in this post.

In the meantime I could index.

Thoughts on that?

[jakobim]

This "app" totally has to be made into a screensaver ... and a digital, landscape clock! Could anybody do this, pretty please!

[twobob]

Thinking about the best approach TBH.

"Yes" is my first instinct but it has to be done carefully not to utterly defeat the point of low power mode.

Believe me I am thinking on it.

[brianinmaine]

it IS pretty, but I wouldn't want to have to plug it in all the time to use it. (although I do have it connected often to my laptop anyway). Maybe it would use less power if it was only updated every minute, not showing a second hand?

I don't like the issue of the menu showing through after a few minutes, does yours do that?