Quote:
Originally Posted by wildcolor
Wow, the technique you mentioned seems to be extremely fansicnating. It goes up to 40FPS on a K4?????????????? I will definitely look into this after work.
Do we actually need to program on the kindle using the technique? Also, I noticed that the kindle always refresh everything completely opposite, say if I display a letter "A". Firstly, the area of the A goes to entirely bright, the A is then rendered to black.
|
Driving the eink at 40FPS is pointless, because it causes too many eink artifacts with general video content. However, with carefully crafted content that is designed to avoid causing eink artifacts, you could drive it that fast. But eink is not like a light emitting display such as a CRT or LCD. If you play the videos I provided, you will see that 7.7FPS is quite adequate. That is all the faster a K3 can do anyway, so I standardized on that AVERAGE update speed. Some frames are a bit faster and some a bit slower, so I insert delays or drop frames as needed to maintain 7.7FPS.
There are different kinds of updates. It is possible to draw on the eink panel without the full flash update. You can see that this is so by watching a video on the eink display (using gmplay mentioned above). It does not flash or flicker.
The K4 does a MUCH better job displaying video if you run it from diags SSH. K4 diags uses the K5 eink drivers (mxc_fb), but when booted from main it uses a K3 eink hardware emulation layer (eink_fb) that is much slower.
EDIT: The kindles NORMALLY only do about 5FPS. You can see examples of that in the various youtube videos for the Nook Simple Touch (Doom and Big Buck Bunny). To get the faster speed, I do not wait for the eink drivers to complete an operation in progress before starting another update. I got the idea from reading the freescale manuals and the eink driver GPL code -- the new K4/K5 eink controller supports 20 simultaneous non-overlapping update threads, and the drivers attempt to automate that by analyzing what changed between framebuffer updates. So, essentially, you can think of my increased eink update speed as a form of eink "overclocking". 
An important point for fast no-flash updates is that the content must not contain any gray pixels (only pure black and white). You can simulate grayscale with dithering, and the ordered dither I use is much faster than other dither methods, and works quite well for video.