[geekmaster]

UPDATE 2: Another complication... When I copy a raw 600x800 image to the framebuffer with dd, which was saved from a JPG image using IrfanView, it displays CORRECTLY on my K5(touch) using this command:

PHP Code:

for i in $(seq 0 1 799);do dd if=barn.raw of=/dev/fb0 bs=1 count=600 skip=$((i*600)) seek=$((i*608)) 2>/dev/null;done;eips '' 


When I write to the framebuffer with a C program, although the framebuffer contains an 8-bit image that I can copy out and view, the eink screen only shows 16 colors. The only possible explanation I have is that perhaps this image is only USING 16 colors and is already dithered from 256 to 16 colors. Hmm...

UPDATE 3: Okay, I just ran the "hoser" demo below, then I used the above command copying from /tmp/wbo instead of from barn.raw, and the result was ONLY 16 COLORS on the eink display (even though the original was a full color JPEG, and it was converted directly to 8-bit grayscale with IrfanView). That means that IrfanView MUST HAVE dithered it down to 16-colors even though I selected 256 color. The wb0 screenshot below shows that it really does contain 256 different shades of gray when viewed on a CRT/LCD display. Hmm... Does this really need to be this complicated?
I just loaded barn.raw into Irfanview and did its histogram function -- 16 spikes showing it only has 16 colors. Hmm... But it looks pretty darned good for 16 colors (amazing how well dithering works when you have tiny little pixels like on these eink displays).

To test K4(mini) and K5(touch) 8-bit framebuffers, I just changed my paldemo program to put the 0-255 color values directly into the framebuffer, and although a SCREENSHOT of the resulting framebuffer shows all 256 shades of gray, the eink display only show 16 shades of gray.

Worse, they are not balanced: values 0-17 display as pure black, but ONLY value 255 displays as pure white.

And what is VERY STRANGE, by viewing the eink screen in a bright light with magnification, you can CLEARLY see that those shades of gray are created by the eink drivers with an ordered dither between two adjacent shades of 4-bit gray.

Now that really begs the question: IF the kindle hardware can only do 16 shades of gray AND the eink drivers use an ordered dither to get JUST THE RIGHT shade of gray, then WHY did they not just dither ALL 256 shades of gray?

This lack of REAL 8-bit support astounds and befuddles me.

Here is a screenshot copied from the framebuffer, and a photo of the K5(Touch) eink display (differences are most visible on the bottom "white" row due to CRT/LCD display gamma):

Spoiler:

Screenshot copied from /dev/fb0 (all 256 grays visible):



Photo of K5(Touch) eink screen (only 16 grays visible):

What you cannot see in the photo shown above is that those 16-shades of gray in the photo use an ordered dither to get those exact shades of gray, so why not dither to 256 shades of gray? What you CAN see is noisy interference between the eink dither pattern and JPEG encoding.

Now it looks like we have to dither to get 256 shades of gray ourselves, but that gives a complication of the eink drivers dithering our dithered output, which can cause nasty Moiré pattern interference where it is NOT WANTED (unlike the spoxbrane and cosmegg demos where it IS wanted ).

This will be quite complicated to work around two layers of dithering. Not nice!

EDIT: Because each of the 16 driver shades of gray is made from two adjacent hardware shades of gray, if we dither two of those "driver grays", our dither interference pattern will contain THREE hardware shades of gray.

UPDATE: I just tested this on a K4 booted from main (with the old eink drivers). It acts differently from a K3 and from a K5 (not unexpected). Each line of the displayed palette is a solid color, so the color quantizing is balanced, but it has ANOTHER problem. The rows for 4-bit colors 11 and 12 are identical, so it can only do 15 shades of gray, not 16. However, I see no dithering, so it appears to be using the shades of gray provided directly by the hardware, with no color or gamma correction like the newer eink drivers appear to be doing. The K4 also displays the palette "upside down" with the whites at the top (values 0-15) and the blacks at the bottom (values 240-255). This just keeps getting more "interesting". Normally, these details are hidden from us inside eips and the Xorg color management layers. Direct hardware access (or at lease low-level framebuffer access) often has these complications, but there is real personal satisfaction obtained by overcoming them.