Quote:
Originally Posted by geekmaster
K4 (Kindle 4 non-touch) and K5 (Kindle touch) use the framebuffer in a different way than the K3 and earlier devices.
Unlike K3 and older which default to 4 bits/pixel, the new K4 and Touch use 8 bits/pixel.
Where the K3 and earlier 6-inch screen models used 300 bytes/row in 600x800 portrait mode, the K4 uses 600 bytes/row, and the Touch uses 608 bytes/row (8 bytes of padding past the last column).
|
My NT uses 608 according to /sys/class/graphics/fb0/stride and virtual_size gives 608,4480.
Quote:
Originally Posted by geekmaster
Newer framebuffer code will need to take stride (byte distance between pixel rows) into account (300, 600, or 608). In addition, these will change for landscape modes for all devices.
*** Another problem is that the Touch is not responding to sending update commands using ioctl (which works fine on the K4). I only see that the framebuffer changed when some external event causes a display update.
And not only is the Touch ioctl call not doing display updates, but my Touch also does NOT have /proc/eink_fb/update_display used by scripts and by some native programs to trigger display updates.
|
Neither does my NT, it doesn't have /proc/eink_fb at all. I can't yet try the ioctl.
Quote:
Originally Posted by geekmaster
Another interesting thing is that the touch has more than twice as many "virtual lines" as it needs. Perhaps the framebuffer contains two screens full of data (double buffered?). I need to study some of the GPL code to figure this out.
At least the K4 is still mostly compatible with the old-style framebuffer control used by many hacks.
The touch will require further investigation.
Here are the eink settings reported by framebuffer ioctl for my kindles:
|
How do you get these? And is there a simple test program for the framebuffer update ioctl?