geekmaster formula 42 (the dithermatron demo)

[geekmaster]

UPDATE: Now that I debricked my K4, I just realized that when I run SSH from wifi, the pixels are the wrong color! Black and white are reversed. The cosmegg demo draws a BLACK egg! I am certain that it draws a white egg when run from diags SSH. My "geekmaster formula 42" assumes that 8-bit framebuffer has black value 0 pixels 4-bit framebuffer has value 0 white. Now the K4 does it BOTH WAYS with a 8-bit framebuffer -- sometimes 0 is white, and sometimes 0 is black. Hmm... Not nice. :

UPDATE 2: I figured this out by putting all the eink fixed and virtual vars for all eink kindles in a spreadsheet and comparing them. The old eink_fb device driver used by DX, DXG, K3, and K4main uses white value 0, but the mxc_epdc_fb device driver used by K4diags, K5main, and K5diags uses black value 0. That means that I when I initialize my eink vars I need to set my black and white color values based on the eink driver and not the bits-per-pixel like I am now, but the formula breaks with the 8-bit inverted. This is more complicated than I thought. Why did the k4 booted from main (which I was not using before -- I used diags SSH) have to be SO different from all other kindles, when diags was just fine?

UPDATE 3: K4 main boot has another eink complication. If supports the /proc eink updates like other devices that use the old driver, but accessing the procs does not insert the delays as it did on K3 and earlier. So it needs to delay like the non-proc eink updates. K4 acts more like a K3 in main boot, but more like a K5(touch) in diags boot.

Spoiler:

This demo shows off the "geekmaster formula 42" branch-free dithered pixel plotting funtion that works on all eink kindle models. I originally implemented it as a long single-line macro, but with modern compilers it is just as fast and (can be) a lot more readable as an inline function. Branch-free code such as this can be a lot faster on processors with limited branch-prediction, which are commonly used in low-power devices.

PHP Code:

//====================================================
// dithermatron 1.1a - kindle eink dynamic dither demo
// Copyright (C) 2012 by geekmaster, with MIT license:
// http://www.opensource.org/licenses/mit-license.php
//----------------------------------------------------
//  The speed is limited by the eink device drivers.
//  Newer kindle models are faster, but need delays.
//  This was tested on DX,DXG,K3,K4(Mini),K5(Touch).
//----------------------------------------------------

#include <stdio.h>      // printf
#include <stdlib.h>    // malloc, free
#include <string.h>   // memset, memcpy
#include <unistd.h>  // usleep
#include <fcntl.h>  // open, close, write
#include <time.h>  // time
#include <sys/mman.h>   // mmap, munmap
#include <sys/ioctl.h> // ioctl
#include <linux/fb.h> // screeninfo

#define ED6 570000      // k4 eink delay best quality
#define ED5 500000     // k4 eink delay good quality
#define ED4 230000    // k4 eink delay K3 speed
#define ED3 100000   // k4 eink delay okay
#define ED2 80000   // k4 eink delay fast
#define ED1 0      // k4 eink delay none, bad
#define K4DLY ED2 // k4 eink delay

enum eupd_op { EUPD_OPEN,EUPD_CLOSE,EUPD_UPDATE };
typedef unsigned char u8;
typedef unsigned int u32;

// function prototypes
void inline setpx(int,int,int);
void box(int,int,int,int);
void line(int,int,int,int,int);
void circle(int,int,int);
int eupdate(int);

// global vars
u8 *fb0=NULL;   // framebuffer pointer
int fdFB=0;    // fb0 file descriptor
u32 fs=0;     // fb0 stride
u32 MX=0;    // xres (visible)
u32 MY=0;   // yres (visible)
u8 blk=0;  // black
u8 wht=0; // white
u8 pb=0; // pixel bits

//===============================================
// dithermatron - kindle eink dynamic dither demo
// This works on all kindle eink models.   Enjoy!
//-----------------------------------------------
void dithermatron(void) {
    int x,y;
    struct fb_var_screeninfo screeninfo;
    fdFB=open("/dev/fb0",O_RDWR); // eink framebuffer

// calculate model-specific vars
    ioctl(fdFB,FBIOGET_VSCREENINFO,&screeninfo);
    MX=screeninfo.xres;  // max X+1
    MY=screeninfo.yres; // max Y+1
    pb=screeninfo.bits_per_pixel;     // pixel bits
    fs=screeninfo.xres_virtual*pb/8; // fb0 stride
    blk=pb/8-1; // black
    wht=~blk;  // white
    fb0=(u8 *)mmap(0,MY*fs,PROT_READ|PROT_WRITE,MAP_SHARED,fdFB,0); // map fb0
    eupdate(EUPD_OPEN); // open fb0 update proc

// do dithered gray demo
    int c=0,px1=MX/2,py1=MY/2,vx1=1,vy1=2,px2=px1,py2=py1,vx2=3,vy2=1;
    int dx,dy,cc=31,cu,cl=3;
    for (cu=0;cu<20000;cu++) {
        if (0==cu%3000) { // periodic background display
          for (y=0; y<=MY/2; y++) {
            for (x=0; x<=MX/2; x++) {
                dx=MX/2-x; dy=MY/2-y; c=65-(dx*dx+dy*dy)*65/(MX*220);
                setpx(x,y,c); setpx(MX-x,y,c);
                setpx(x,MY-y,c); setpx(MX-x,MY-y,c);
            }
          }
        }
        box(px1,py1,80,0); box(px1,py1,81,64);
        box(px1,py1,82,64); box(px1,py1,83,cc);
        circle(px2,py2,50); circle(px2,py2,51); circle(px2,py2,52);
        circle(px1+80,py1+80,20); circle(px1+80,py1-80,20);
        circle(px1-80,py1+80,20); circle(px1-80,py1-80,20);
        px1+=vx1; if (px1>MX-110 || px1<110) vx1=-vx1;
        py1+=vy1; if (py1>MY-110 || py1<110) { vy1=-vy1; cl++; }
        px2+=vx2; if (px2>MX-60 || px2<60) vx2=-vx2;
        py2+=vy2; if (py2>MY-60 || py2<60) { vy2=-vy2; cl++; }
        if (0==cu%cl) { eupdate(EUPD_UPDATE); } // update display
        cc=(cc+1)%65; // cycle big box color
    }

// cleanup - close and free resources
    eupdate(EUPD_UPDATE);    // update display
    eupdate(EUPD_CLOSE);    // close fb0 update proc port
    munmap(fb0,fs*(MY+1)); // unmap fb0
    close(fdFB);          // close fb0
}

//===============================
// eupdate - eink update display
// op (open, close, update)
//-------------------------------
int eupdate(int op) {
    static int fdUpdate=-1;
    if (EUPD_OPEN==op) { fdUpdate=open("/proc/eink_fb/update_display",O_WRONLY);
    } else if (EUPD_CLOSE==op) { close(fdUpdate);
    } else if (EUPD_UPDATE==op) {
        if (-1==fdUpdate) { system("eips ''"); usleep(K4DLY);
        } else { write(fdUpdate,"1\n",2); }
    } else { return -1; }
    return fdUpdate;
}

//========================================
// setpx - draw pixel using ordered dither
// x,y: screen coordinates, c: color(0-64).
// (This works on all eink kindle models.)
//----------------------------------------
void inline setpx(int x,int y,int c) {
    static int dt[64] = { 1,33,9,41,3,35,11,43,49,17,57,25,51,19,59,27,13,45,5,
    37,15,47,7,39,61,29,53,21,63,31,55,23,4,36,12,44,2,34,10,42,52,20,60,28,50,
    18,58,26,16,48,8,40,14,46,6,38,64,32,56,24,62,30,54,22 }; // dither table
    fb0[pb*x/8+fs*y]=((128&(c-dt[(7&x)+8*(7&y)]))/128*(blk&(240*(1&~x)|
        15*(1&x)|fb0[pb*x/8+fs*y])))|((128&(dt[(7&x)+8*(7&y)]-c))/128*wht|
        (blk&((240*(1&x)|15*(1&~x))&fb0[pb*x/8+fs*y]))); // geekmaster formula 42
}

//======================
// box - simple box draw
//----------------------
void box(int x,int y,int d,int c) {
    int i;
    for (i=0;i<d;++i) {
        setpx(x+i,y+d,c); setpx(x+i,y-d,c); setpx(x-i,y+d,c); setpx(x-i,y-d,c);
        setpx(x+d,y+i,c); setpx(x+d,y-i,c); setpx(x-d,y+i,c); setpx(x-d,y-i,c);
    }
}
//==================================
// line - Bresenham's line algorithm
//----------------------------------
void line(int x0,int y0,int x1,int y1,int c) {
    int dx,ny,sx,sy,e;
    if (x1>x0) { dx=x1-x0; sx=1; } else { dx=x0-x1; sx=-1; }
    if (y1>y0) { ny=y0-y1; sy=1; } else { ny=y1-y0; sy=-1; }
    e=dx+ny;
    for (;;) { setpx(x0,y0,c);
        if (x0==x1&&y0==y1) { break; }
        if (e+e>ny) { e+=ny; x0+=sx; }
        if (e+e<dx) { e+=dx; y0+=sy; }
    }
}

//==============================================
// circle - optimized midpoint circle algorithm
//----------------------------------------------
void circle(int cx,int cy,int r) {
    int e=-r,x=r,y=0;
    while (x>y) {
        setpx(cx+y,cy-x,64); setpx(cx+x,cy-y,40);
        setpx(cx+x,cy+y,24); setpx(cx+y,cy+x,8);
        setpx(cx-y,cy+x,0); setpx(cx-x,cy+y,16);
        setpx(cx-x,cy-y,32); setpx(cx-y,cy-x,48);
        e+=y; y++; e+=y;
        if (e>0) { e-=x; x-=1; e-=x; }
    }
}

//==================
// main - start here
//------------------
int main(void) {
    dithermatron(); // do the dithermatron demo :D
    return 0;
} 


This is the result of my "1) Make it work, 2) Make it small, 3) Make it fast" development process for kindle eink displays. Although the "line" function is not used here, I left it in for future expansion. Go ahead and use it (it *should* work).

I spent a lot of time watching this graphical animation demo program run, and you might too. It gets much faster as it runs to completion, so it is worth watching "all the way" at least one time. Feel free to modify this code to do OTHER cool graphical stuff, now that we have fast "grayscale" pixels to play with (and easy to use, too). Executable binary demo program in download below. Enjoy and learn!

EDIT: Because the speed is determined by the display update routines, you really need to watch this on the newer K4(mini) or K5(touch) to see it run at full speed (less than 2 minutes to completion). But it runs okay on a DX too -- just not in "real-time".

[wolftail]

The animation was fast. Quite a lot of fps. I like where this is going. Who said eInk is slow?

[varnie]

Awesome as always. I am glad you share your knowledge with us, GeekMaster!
By the way, did you notice any valuable changes (or maybe even quirks) in the eips utility on the latest KT firmware update? Thanks in advance.

[MaPePeR]

E-Ink allways makes me think about Etch a Sketch so: I'm wondering if heavy animations and a lot of refreshes will "damage" the screen?
We already have seen Videos playing on E-Ink screens, but they are not designed for that - so can E-Ink handle that?

(Other examples of similiar behaivior would be a flash-memory or a light bulb)

[geekmaster]

Originally Posted by MaPePeR

E-Ink allways makes me think about Etch a Sketch so: I'm wondering if heavy animations and a lot of refreshes will "damage" the screen?
We already have seen Videos playing on E-Ink screens, but they are not designed for that - so can E-Ink handle that?

(Other examples of similiar behaivior would be a flash-memory or a light bulb)

My experience shows that the eink gets faster and higher contrast with use. When it has been stored awhile, it is slower with washed-out blacks and whites. It gets better with use. Also, it appears that they are calibrated for 25C (77F) which is usually warmer than ambient temperature so needs to warm up a bit (from use) to get up to its preferred operating temperature.

Scientifically, these screens use eink made of many tiny beads filled with zinc oxide powder mixed into a dark oil. Oil viscosity changes with temperature, making the zinc particles move slower when cold and faster when warm. And the oil is hermitically sealed and should not "wear out".

So, I would say no, it will not wear out, and using it will only make it better.

[geekmaster]

Originally Posted by wolftail

The animation was fast. Quite a lot of fps. I like where this is going. Who said eInk is slow?

Oops... I see that a recent change I made makes it segfault at the BEGINNING of the animation on the touch. It was hmm... My screen looks just like yours. There is MUCH more to this animation. I will fix it...

I just tested it on my K3 and DX, and it works there. Ahh... I see that I put an old executable in the .gz file... I will rezip it...

[geekmaster]

Updated to v1.1, which fixes a bug that made the program on a K4(mini) or K5(touch) quit much too early (when the box touched the bottom of the screen). I also made it begin at a faster speed (as though both objects had already touched the bottom).

If you thought the incomplete run was interesting, watch this one.

[geekmaster]

Here is another "geekmaster formula 42" demo. You can guess this one from the name.

Spoiler:

PHP Code:

//====================================================
// eLips 1.0 - kindle eink electrolips demo
// Copyright (C) 2012 by geekmaster, with MIT license:
// http://www.opensource.org/licenses/mit-license.php
//----------------------------------------------------
//  The speed is limited by the eink device drivers.
//  Newer kindle models are faster, but need delays.
//  This was tested on DX,DXG,K3,K4(Mini),K5(Touch).
//----------------------------------------------------

#include <stdio.h>      // printf
#include <stdlib.h>    // malloc, free, atoi
#include <string.h>   // memset, memcpy
#include <unistd.h>  // usleep
#include <fcntl.h>  // open, close, write
#include <time.h>  // time
#include <sys/ioctl.h>   // ioctl
#include <sys/time.h>   // gettime
#include <sys/mman.h>  // mmap, munmap
#include <linux/fb.h> // screeninfo

#define FPS 5 // max frames/sec

enum eupd_op { EUPD_OPEN,EUPD_CLOSE,EUPD_UPDATE };
typedef unsigned char u8;
typedef unsigned int u32;

// function prototypes
inline void setpx(int,int,int);
int eupdate(int);
int getmsec(void);

// global vars
u32 mpu=1000/FPS;// msec/update
u8 *fb0=NULL;   // framebuffer pointer
int fdFB=0;    // fb0 file descriptor
u32 fs=0;     // fb0 stride
u32 MX=0;    // xres (visible)
u32 MY=0;   // yres (visible)
u8 blk=0;  // black
u8 wht=0; // white
u8 pb=0; // pixel bits

//===============================================
// electrolips - kindle electrolips demo
// This works on all kindle eink models.   Enjoy!
//-----------------------------------------------
void eLips(void) {
    int x,y,tn;
    struct fb_var_screeninfo screeninfo;
    fdFB=open("/dev/fb0",O_RDWR); // eink framebuffer

// calculate model-specific vars
    ioctl(fdFB,FBIOGET_VSCREENINFO,&screeninfo);
    MX=screeninfo.xres;  // max X+1
    MY=screeninfo.yres; // max Y+1
    pb=screeninfo.bits_per_pixel;     // pixel bits
    fs=screeninfo.xres_virtual*pb/8; // fb0 stride
    blk=pb/8-1; // black
    wht=~blk;  // white
    fb0=(u8 *)mmap(0,MY*fs,PROT_READ|PROT_WRITE,MAP_SHARED,fdFB,0); // map fb0
    eupdate(EUPD_OPEN); // open fb0 update proc

// do dithered gray demo
    int c,dx,dy,cu,px1=MX/2,py1=MY/2,vx1=77,vy1=57;
    for (cu=0;cu<1000;cu++) { tn=mpu+getmsec();
        for (y=0; y<=MY/2; y++) {
            for (x=0; x<=MX/2; x++) {
                dx=MX/2-x+px1/2; dy=MY/2-y+py1/3; c=65-(dx*dx+dy*dy)*65/(MX*220);
                setpx(x,y,c); setpx(MX-x,y,c);
                setpx(x,MY-y,c); setpx(MX-x,MY-y,c);
            }
        }
        px1+=vx1; if (px1>MX-40 || px1<40) vx1=-vx1;
        py1+=vy1; if (py1>MY-40 || py1<40) vy1=-vy1;
        eupdate(EUPD_UPDATE); // update display
        while (tn>getmsec()); // wait until next update time
    }

// cleanup - close and free resources
    eupdate(EUPD_UPDATE);    // update display
    eupdate(EUPD_CLOSE);    // close fb0 update proc port
    munmap(fb0,fs*(MY+1)); // unmap fb0
    close(fdFB);          // close fb0
}

//===============================
// eupdate - eink update display
// op (open, close, update)
//-------------------------------
int eupdate(int op) {
    static int fdUpdate=-1;
    if (EUPD_OPEN==op) { fdUpdate=open("/proc/eink_fb/update_display",O_WRONLY);
    } else if (EUPD_CLOSE==op) { close(fdUpdate);
    } else if (EUPD_UPDATE==op) {
        if (-1==fdUpdate) { system("eips ''");
        } else { write(fdUpdate,"1\n",2); }
    } else { return -1; } // bad op code
    return fdUpdate;
}

//========================================
// setpx - draw pixel using ordered dither
// x,y: screen coordinates, c: color(0-64).
// (This works on all eink kindle models.)
//----------------------------------------
inline void setpx(int x,int y,int c) {
    static int dt[64] = { 1,33,9,41,3,35,11,43,49,17,57,25,51,19,59,27,13,45,5,
    37,15,47,7,39,61,29,53,21,63,31,55,23,4,36,12,44,2,34,10,42,52,20,60,28,50,
    18,58,26,16,48,8,40,14,46,6,38,64,32,56,24,62,30,54,22 }; // dither table
    fb0[pb*x/8+fs*y]=((128&(c-dt[(7&x)+8*(7&y)]))/128*(blk&(240*(1&~x)|
        15*(1&x)|fb0[pb*x/8+fs*y])))|((128&(dt[(7&x)+8*(7&y)]-c))/128*wht|
        (blk&((240*(1&x)|15*(1&~x))&fb0[pb*x/8+fs*y]))); // geekmaster formula 42
}

//====================================
// getmsec - get msec since first call
// (tick counter wraps every 12 days)
//------------------------------------
int getmsec(void) {
    int tc;
    static int ts=0;
    struct timeval tv;
    gettimeofday(&tv,NULL); tc=tv.tv_usec/1000+1000*(0xFFFFF&tv.tv_sec);
    if (0==tc) { ts=tc; }
    return tc-ts;
}

//==================
// main - start here
//------------------
int main(void) {
    eLips(); // do the electrolips demo :D
    return 0;
} 


Enjoy and learn!

[geekmaster]

Another "geekmaster formula 42" demo. And another one you can guess from its name.

Spoiler:

PHP Code:

//====================================================
// cosmegg 1.0 - kindle cosmic egg demo
// Copyright (C) 2012 by geekmaster, with MIT license:
// http://www.opensource.org/licenses/mit-license.php
//----------------------------------------------------
//  The speed is limited by the eink device drivers.
//  Newer kindle models are faster, but need delays.
//  This was tested on DX,DXG,K3,K4(Mini),K5(Touch).
//----------------------------------------------------

#include <stdio.h>      // printf
#include <stdlib.h>    // malloc, free, atoi
#include <string.h>   // memset, memcpy
#include <unistd.h>  // usleep
#include <fcntl.h>  // open, close, write
#include <time.h>  // time
#include <sys/ioctl.h>   // ioctl
#include <sys/time.h>   // gettime
#include <sys/mman.h>  // mmap, munmap
#include <linux/fb.h> // screeninfo

#define FPS 5 // max frames/sec

enum eupd_op { EUPD_OPEN,EUPD_CLOSE,EUPD_UPDATE };
typedef unsigned char u8;
typedef unsigned int u32;

// function prototypes
inline void setpx(int,int,int);
int eupdate(int);
void line(int,int,int,int,int);
void circle(int,int,int);
int getmsec(void);

// global var7
u32 mpu=200;      // msec/update
u8 *fb0=NULL;   // framebuffer pointer
int fdFB=0;    // fb0 file descriptor
u32 fs=0;     // fb0 stride
u32 MX=0;    // xres (visible)
u32 MY=0;   // yres (visible)
u8 blk=0;  // black
u8 wht=0; // white
u8 pb=0; // pixel bits

//===============================================
// cosmegg - kindle cosmic egg demo
// This works on all kindle eink models.   Enjoy!
//-----------------------------------------------
void cosmegg(void) {
    int x,y,tn;
    struct fb_var_screeninfo screeninfo;
    fdFB=open("/dev/fb0",O_RDWR); // eink framebuffer

// calculate model-specific vars
    ioctl(fdFB,FBIOGET_VSCREENINFO,&screeninfo);
    MX=screeninfo.xres;  // max X+1
    MY=screeninfo.yres; // max Y+1
    pb=screeninfo.bits_per_pixel;     // pixel bits
    fs=screeninfo.xres_virtual*pb/8; // fb0 stride
    blk=pb/8-1; // black
    wht=~blk;  // white
    fb0=(u8 *)mmap(0,MY*fs,PROT_READ|PROT_WRITE,MAP_SHARED,fdFB,0); // map fb0
    eupdate(EUPD_OPEN); // open fb0 update proc

// do dithered gray demo
    int c,dx,dy,cu;
    for (cu=250000;cu>100;cu-=(cu/100)) { tn=mpu+getmsec();
        for (y=0; y<MY; y++) for (x=0; x<MX; x++) { dx=(x-MX*2/5); dy=(y-MY/2);
            c=64-((dx*dx+dy*dy-(x*y-4*x)/4)*65/cu)%65; setpx(x,y,c);
        } eupdate(EUPD_UPDATE); // update display
        while (tn>getmsec()); // wait until next update time
    }

// cleanup - close and free resources
    eupdate(EUPD_UPDATE);    // update display
    eupdate(EUPD_CLOSE);    // close fb0 update proc port
    munmap(fb0,fs*(MY+1)); // unmap fb0
    close(fdFB);          // close fb0
}

//===============================
// eupdate - eink update display
// op (open, close, update)
//-------------------------------
int eupdate(int op) {
    static int fdUpdate=-1;
    if (EUPD_OPEN==op) { fdUpdate=open("/proc/eink_fb/update_display",O_WRONLY);
    } else if (EUPD_CLOSE==op) { close(fdUpdate);
    } else if (EUPD_UPDATE==op) {
        if (-1==fdUpdate) { system("eips ''");
        } else { write(fdUpdate,"1\n",2); }
    } else { return -1; } // bad op code
    return fdUpdate;
}

//========================================
// setpx - draw pixel using ordered dither
// x,y: screen coordinates, c: color(0-64).
// (This works on all eink kindle models.)
//----------------------------------------
inline void setpx(int x,int y,int c) {
    static int dt[64] = { 1,33,9,41,3,35,11,43,49,17,57,25,51,19,59,27,13,45,5,
    37,15,47,7,39,61,29,53,21,63,31,55,23,4,36,12,44,2,34,10,42,52,20,60,28,50,
    18,58,26,16,48,8,40,14,46,6,38,64,32,56,24,62,30,54,22 }; // dither table
    fb0[pb*x/8+fs*y]=((128&(c-dt[(7&x)+8*(7&y)]))/128*(blk&(240*(1&~x)|
        15*(1&x)|fb0[pb*x/8+fs*y])))|((128&(dt[(7&x)+8*(7&y)]-c))/128*wht|
        (blk&((240*(1&x)|15*(1&~x))&fb0[pb*x/8+fs*y]))); // geekmaster formula 42
}

//====================================
// getmsec - get msec since first call
// (tick counter wraps every 12 days)
//------------------------------------
int getmsec(void) {
    int tc;
    static int ts=0;
    struct timeval tv;
    gettimeofday(&tv,NULL); tc=tv.tv_usec/1000+1000*(0xFFFFF&tv.tv_sec);
    if (0==tc) { ts=tc; }
    return tc-ts;
}

//==================
// main - start here
//------------------
int main(int argc,char **argv) {
    if (argc>1) { mpu=atoi(argv[1]); }
    cosmegg(); // do the cosmic egg demo :D
    return 0;
} 


Enjoy and learn!

[giorgio130]

What do you think is making the newer models' screen faster? the cpu? maybe we could try to overclock a little to get them even speedier...

[geekmaster]

On my DX, I need to run these in the background, or they quit when my telnet connection drops with "Connection closed by foreign host." error (common on long telnet connections to kindles -- ssh is more reliable).

For example,

/mnt/us/dithermatron &

/mnt/us/eLips &

/mnt/us/cosmegg &

That way it keeps running to completion even after my telnet connection drops.

And it helps a LOT to clear the screen before running these:

eips -c ==> this works on any eink kindle.

eips -c -f ==> on K4(mini) or K5(touch), display looks much cleaner with '-f'.

Enjoy and learn!

[hawhill]

Really nice demos. On my K3, 50% of the CPU time is spent in the Kernel (according to unreliable "top"). Probably, the eink driver could be a bit more optimized...

[root@kindle us]# time ./cosmegg  
real	3m 56.15s
user	2m 9.67s
sys	1m 46.24s

The Moiré effects in the Cosmegg demo are nice :-)

[geekmaster]

Originally Posted by giorgio130

What do you think is making the newer models' screen faster? the cpu? maybe we could try to overclock a little to get them even speedier...

The screen updates behave differently on the old and new kindles.

On the K3 and earlier, they were blocking calls, where the write to the udpate proc or the ioctl call or the eips command did not return until the display update was complete.

On the K4(mini) and K5(touch), the calls all return immediately before the update even begins, and the drivers can stack up 32 pending updates, and it will try to "combine" them. This can make the updates a lot faster for small changes, but if you write to the framebuffer too soon for large changes, you can nasty screen tearing artifacts, or strange delayed "ghosting" while the eink drivers catch up on a trail of partial updates. When you wait on writes, the drivers can complete, but for animation it looks ugly if you do not wait long enough after an eink update is triggered.

In my older code, I added a delay (K4DLY) to the kindles that fail opening the update proc file. The problem was that a lot of processing to create a screen already delayed it some, and the full additional delay was not needed in that case.

In my newer code, I use a timer (gettmsec()) to determine WHEN it is safe to do another update (effectively setting a fixed framerate). This works quite well.

In new (unfinished) code, I using double-buffered display updates. I am NOT writing directly to the framebuffer, but instead to a temp copy of the framebuffer. Then just before the update call I quickly COPY my temp copy to /dev/fb0. This prevents the eink drivers from getting all "confused" because we are writing to the framebuffer while it is trying to use it. This should increase the speed without causing extra annoying display "tearing" artifacts.

At least, that is the plan...

I do not think increasing the CPU speed will make the eink drivers run any faster, and that is the bottleneck right now.

[geekmaster]

Originally Posted by hawhill

Really nice demos. On my K3, 50% of the CPU time is spent in the Kernel (according to unreliable "top"). Probably, the eink driver could be a bit more optimized...

[root@kindle us]# time ./cosmegg  
real	3m 56.15s
user	2m 9.67s
sys	1m 46.24s

The Moiré effects in the Cosmegg demo are nice :-)

Now that ixtab has a K3 kernel with kexec, we can fix that kernel eink optimization issue.

EDIT: What goes on the display is just the same old boring stuff I have been doing since the "big iron" mainframe days of printing these on fan-fold line-printer paper and hanging them around my office. I do similar algorithms with SOUND too, by connecting an output bit to a speaker. People say the sounds are "hypnotic". I had a large collection of totally different but very interesting sound algorithms back in the day, and I could re-create most of them pretty easily. This stuff works the same for sound and light. On the K4(mini), I could PWM the power LED, and a photocell connected to amplified speakers would do the trick.

What I want to know is your opinion of the "re-usability factor" of my code. Is it simple enough for beginning programmers? Is it small enough to not scare people away (i.e. "above the fold")? There are no modules to link, no header files to worry about. Just "arm-linux-gcc -o demo demo.c" and you are good to go. I try to follow the "Make it work, then make it small, then make it fast" philosophy. What is your opinion about my SOURCE CODE? Do you like these C proggies better than my /bin/sh scripts?

[PoP]

<<What is your opinion about my SOURCE CODE? Do you like these C proggies better than my /bin/sh scripts?>> geekmaster

This is such a personal question... my 2 cents: I find your code compact and elegant. Though C is more powerful and easier to understand, Shell is more fun (minimalist language demanding plenty of ingenious techniques). In my opinion compact code can sometimes be cryptic (e.g. APL ) but verbose code can quickly become boring (e.g. COBOL ). Nothing that should scare beginners away -- to the contrary. Your spectacular demos will set interested minds in motion. Thanks for sharing them.

... And by the way I liked the cosmic egg hypnotic screen effects:

Spoiler:

Are you sure?

Spoiler:

Really sure?

Spoiler:

Then Click At Your Own Risk: