Quote:
Originally Posted by hawhill
- - - -
The kernel framebuffer driver is an easier target (with "easy" meaning that you are given the source code, you "just" have to be a kernel framebuffer driver hacker). A drop-in replacement for the kernel framebuffer driver implementing 1-bit dithering is a feasible task.
However, I'm not convinced that there really are scenarios where you would want the full Kindle user experience dithered to black and white.
|
I agree with the "would not want the full..."
The Amazon provided software is already writing in 4-bit grayscale.
Any replacement kernel framebuffer **should** continue to recognize the existing Amazon rendering layouts and interface.
So a rendering algorithm (or its implementation) should pass true 4-bit grayscale unmodified.
But this is just a grayscale variation on the old "Safe Web Colors" problem, when only 8-bit color displays where still common.
How would "Safe Grayscale" be identified for "pass through" - -
Two possibilities occur to me (with a byte-per-pixel storage plan) -
* Force the high order nibble to zero (some Kindle drivers require this)
* Force the high order nibble to be the identical value as the low order nibble (some Kindle drivers require this).
The above is not to say that the Kindle rendering hardware will dither **now** if the above requirements are not met.
But the requirements may exist now to support future (if not now present) hardware dithering.
That would handle 8-bit (or less) grayscale to 4-bit grayscale dithering.
Unfortunately, my framebuffer-fu is not up to the task of writing a loadable dithering layer module to the kernel's lab126 driver stack.
To handle 12-bit (or more) grayscale to 4-bit grayscale would have to be new kernel driver calls or be handled by the application that uses greater than 8-bit grayscale.
I.E: To display grayscale DICOM images.
To get a medical image that appears as more than just a smudge on the Kindles will take a bit (no pun intended) DIY rendering fu