K4 and Touch framebuffer changes

geekmaster · 12-17-2011, 09:48 PM

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).

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.

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:

Touch (a/k/a KT or K5):

Spoiler:

K4 (non-touch):

Spoiler:

K3 (Keyboard):

Spoiler:

DXG (Graphite):

Spoiler:

DX (White):

Spoiler:

I do not yet have a K2 or K1, but I would really like to get them for testing. Does anybody have an old one no longer loved, neglected in a drawer, on a shelf, in a closet, or under a bed (or packed away in a box)? I am sure it would love a new home where it will get plenty of attention.

geekmaster · 12-18-2011, 02:49 PM

A lot of the /proc/ stuff is different on the Touch as well. It will be interesting trying to port old hacks to the Touch...

Serpentine · 12-18-2011, 06:50 PM

I wouldn't be surprised if the double height of the Touch virtual res is to do with the touch, either to store an interaction map to map between, for faster key press effects, or as a mask. That said, the padding on that rows and the extra padding might also have something to do with holding touch data, maybe trying to skip bringing things out of a lower state until there's some actual processing to be done.

Be interesting to have a look at the mem referenced. Nice info tho.

Ethan G · 02-22-2012, 01:07 PM

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?

geekmaster · 02-22-2012, 04:22 PM

Quote:

Originally Posted by Ethan G

My NT uses 608 according to /sys/class/graphics/fb0/stride and virtual_size gives 608,4480.

Neither does my NT, it doesn't have /proc/eink_fb at all. I can't yet try the ioctl.

How do you get these? And is there a simple test program for the framebuffer update ioctl?

Even the old kindle has the "eips" command. "eips -i" shows information about the framebuffer. "eips -g" will display images on the screen. "eips <x> <y> 'text'" will display text.

What I have been doing to update the display (even in C programs) is "eips ''" (that is two single-quotes following eips).

As I understand it, there is a different ioctl call to use with the new kindles, but it did not work for me -- I plan to replace the system("eips ''"); calls with ioctl calls "some day"...

And eips even works on kindle 3 and kindle DX, so it is "more portable" than ioctl calls or /proc/. It is easy to use eips in scripts as well...

Ethan G · 02-22-2012, 04:33 PM

hahaha! Thanks for the info, geekmaster. "eips ''" suits me fine.

knc1 · 02-23-2012, 11:28 AM

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.

Been a few variations in the hardware eink drivers also:

Code:

root:cat$ grep 'drivers/video/eink' Amazon_2012.02.18_sha1.cat | sort --key=1.1,1.40 -u | wc -l
198

May take some time to sort out what are simply kernel-version changes and what are functional changes.
But going by the pathnames and filenames - there have been several __different__ driver organizations.

True - the directFB layer is __supposed to__ hide those changes, but....

Ethan G · 05-17-2014, 08:21 AM

Quote:

Originally Posted by Ethan G

My NT uses 608 according to /sys/class/graphics/fb0/stride and virtual_size gives 608,4480.

I just started tinkering with my NT again, and found a curious thing: the above figures only apply when the screen hasn't been rotated. I used eips this time; from boot until the first rotate it gives xres_virtual: 608, yres_virtual: 4480. Via the framework I rotated it to landscape and then back to its original orientation, and after that the virtual figures matched the physical.

knc1 · 05-17-2014, 08:45 AM

Now that is very strange indeed.
Did both xres and yres change?

Ethan G · 05-17-2014, 11:48 AM

Yep, and some other values too. In particular, rotate goes to 0 whether it's in portrait or landscape mode. I didn't look in any sys files this time around, I just used eips. Even the amount of memory in "fixed framebuffer info" changes, I didn't notice that before. Heh, "Is your Kindle NT running slow? Rotate the screen to speed it up!"

Before:

Code:

Fixed framebuffer info
    id:              mxc_epdc_fb    smem_start:       0x75400000
    smem_len:            2560000    type:          PACKED_PIXELS
    type_aux:                  0    visual:   STATIC_PSEUDOCOLOR
    xpanstep:                  1    ypanstep:                  1
    ywrapstep:                 0    line_length:             608
    mmio_start:       0x00000000    mmio_len:                  0
    accel:                     0

Variable framebuffer info
    xres:                    600    yres:                    800
    xres_virtual:            608    yres_virtual:           4480
    xoffset:                   0    yoffset:                   0
    bits_per_pixel:            8    grayscale:                 1
    red.offset:                0    green.offset:              0
    red.length:                8    green.length:              8
    red.msb_right:             0    green.msb_right:           0
    blue.offset:               0    transp.offset:             0
    blue.length:               8    transp.length:             0
    blue.msb_right:            0    transp.msb_right:          0
    nonstd:                    0    activate:                192
    width:                    -1    height:                   -1
    accel_flags:               0    pixclock:           32000000
    left_margin:              17    right_margin:            172
    upper_margin:              4    lower_margin:             18
    hsync_len:                15    vsync_len:                 4
    sync:                      0    vmode:                     0
    rotate:                    1

After:

Code:

Fixed framebuffer info
    id:                  eink_fb    smem_start:       0xD0B8E000
    smem_len:             966656    type:          PACKED_PIXELS
    type_aux:                  0    visual:   STATIC_PSEUDOCOLOR
    xpanstep:                  0    ypanstep:                  0
    ywrapstep:                 0    line_length:             600
    mmio_start:       0x00000000    mmio_len:                  0
    accel:                     0

Variable framebuffer info
    xres:                    600    yres:                    800
    xres_virtual:            600    yres_virtual:            800
    xoffset:                   0    yoffset:                   0
    bits_per_pixel:            8    grayscale:                 1
    red.offset:                0    green.offset:              0
    red.length:                0    green.length:              0
    red.msb_right:             0    green.msb_right:           0
    blue.offset:               0    transp.offset:             0
    blue.length:               0    transp.length:             0
    blue.msb_right:            0    transp.msb_right:          0
    nonstd:                    0    activate:                  2
    width:                    91    height:                  121
    accel_flags:               0    pixclock:                  0
    left_margin:               0    right_margin:              0
    upper_margin:              0    lower_margin:              0
    hsync_len:                 0    vsync_len:                 0
    sync:                      0    vmode:                     0
    rotate:                    0

knc1 · 05-17-2014, 12:54 PM

Even the driver name changes.(*)
At least both are 8bpp - but that is about all that is the same.

* Probably losing the pointer to the correct driver structure when restoring the original orientation (an 'extra' layer of indirection? points at the driver rather than the upper "driver shim"?) -

as I recall, the K4 is one that uses some "driver shims" on top of the K3 driver.
Or some other weird driver mess.

If the K4 was still in production, it might be worth fixing it.

[Whoot! 5,900! I gotta get a life.]

Ethan G · 05-17-2014, 11:25 PM

It's a mess one way or another! Still, a mess is what I expect from Linux systems these days. I was happy to see a build environment for static binaries with tcc.

I got ideas from your build instructions and set out to try to make a tcc+musl build environment, but before I got very far a friend convinced me to port the 9front fork of the Plan 9 operating system instead. I'm excited and scared, I love 9front but I've never done any driver development before! I won't go into detail here, I'm way off topic already, but I'll post about my progress and my reasons for doing it if and when I get anywhere.

knc1 · 05-18-2014, 08:54 AM

I did build the Plan9 kernel module for the Kindles.
Never did hear from anyone who tried it.

Ethan G · 05-19-2014, 08:08 PM

I guess that's a typo, because taken at face value, saying "the Plan9 kernel module" is like asking "What version of Windows do you need to run Linux?"

Do you mean v9fs, the 9p filesystem module for Linux? Or do you have secret code from the long-forgotten Glendix project?

12-17-2011, 09:48 PM	#1
geekmaster Carpe diem, c'est la vie. Posts: 6,433 Karma: 10773668 Join Date: Nov 2011 Location: Multiverse 6627A Device: K1 to PW3	K4 and Touch framebuffer changes 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). 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. 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: Touch (a/k/a KT or K5): Spoiler: Code: finfo: id=mxc_epdc_fb smem_start=75100000 smem_len=1024000 type=0 type_aux=0 visual=5 xpanstep=1 ypanstep=1 ywrapstep=0 line_length=608 mmio_start=00000000 mmio_len=0 accel=0 vinfo: xres=600 yres=800 xres_virt=608 yres_virt=1792 xoffset=0 yoffset=0 bitsperpixel=8 grayscale=1 nonstd=0 activate=128 height=-1 width=-1 flags=0 pixclk=32258064 lmargin=17 rmargin=172 umargin=4 bmargin=18 hsync_len=15 vsync_len=4 sync=0 vmode=0 K4 (non-touch): Spoiler: Code: finfo: id=eink_fb smem_start=d0b8e000 smem_len=966656 type=0 type_aux=0 visual=5 xpanstep=0 ypanstep=0 ywrapstep=0 line_length=600 mmio_start=00000000 mmio_len=0 accel=0 vinfo: xres=600 yres=800 xres_virt=600 yres_virt=800 xoffset=0 yoffset=0 bitsperpixel=8 grayscale=1 nonstd=0 activate=2 height=121 width=91 flags=0 pixclk=0 lmargin=0 rmargin=0 umargin=0 bmargin=0 hsync_len=0 vsync_len=0 sync=0 vmode=0 K3 (Keyboard): Spoiler: Code: finfo: id=eink_fb smem_start=d08a8000 smem_len=483328 type=0 type_aux=0 visual=5 xpanstep=0 ypanstep=0 ywrapstep=0 line_length=300 mmio_start=00000000 mmio_len=0 accel=0 vinfo: xres=600 yres=800 xres_virt=600 yres_virt=800 xoffset=0 yoffset=0 bitsperpixel=4 grayscale=1 nonstd=0 activate=2 height=121 width=91 flags=0 pixclk=0 lmargin=0 rmargin=0 umargin=0 bmargin=0 hsync_len=0 vsync_len=0 sync=0 vmode=0 rotate=0 DXG (Graphite): Spoiler: Code: finfo: id=eink_fb smem_start=c8909000 smem_len=991232 type=0 type_aux=0 visual=5 xpanstep=0 ypanstep=0 ywrapstep=0 line_length=412 mmio_start=00000000 mmio_len=0 accel=0 vinfo: xres=824 yres=1200 xres_virt=824 yres_virt=1200 xoffset=0 yoffset=0 bitsperpixel=4 grayscale=1 nonstd=0 activate=2 height=203 width=139 flags=0 pixclk=0 lmargin=0 rmargin=0 umargin=0 bmargin=0 hsync_len=0 vsync_len=0 sync=0 vmode=0 rotate=0 DX (White): Spoiler*: Code: finfo: id=eink_fb smem_start=c8909000 smem_len=991232 type=0 type_aux=0 visual=5 xpanstep=0 ypanstep=0 ywrapstep=0 line_length=412 mmio_start=00000000 mmio_len=0 accel=0 vinfo: xres=824 yres=1200 xres_virt=824 yres_virt=1200 xoffset=0 yoffset=0 bitsperpixel=4 grayscale=1 nonstd=0 activate=2 height=203 width=139 flags=0 pixclk=0 lmargin=0 rmargin=0 umargin=0 bmargin=0 hsync_len=0 vsync_len=0 sync=0 vmode=0 rotate=0 I do not yet have a K2 or K1, but I would really like to get them for testing. Does anybody have an old one no longer loved, neglected in a drawer, on a shelf, in a closet, or under a bed (or packed away in a box)? I am sure it would love a new home where it will get plenty of attention. Last edited by geekmaster; 12-17-2011 at 10:17 PM.*

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Eink Framebuffer Update Trigger	geekmaster	Kindle Developer's Corner	36	12-28-2019 06:24 PM
Kindle Touch, Nook Touch or Kobo Touch?	tron_1970	Which one should I buy?	33	05-01-2012 12:15 PM
e-ink/reader framebuffer device (killed it, sorta)	tarvoke	enTourage eDGe	26	01-08-2012 04:58 AM
Kindle Qt embedded framebuffer driver	hassan	Kindle Developer's Corner	2	08-20-2011 10:31 PM
Kindle 3, Nook Simple Touch, Kobo Touch and Libra Pro Touch	jbcohen	Which one should I buy?	4	06-18-2011 07:58 PM

12-18-2011, 02:49 PM	#2
geekmaster Carpe diem, c'est la vie. Posts: 6,433 Karma: 10773668 Join Date: Nov 2011 Location: Multiverse 6627A Device: K1 to PW3	A lot of the /proc/ stuff is different on the Touch as well. It will be interesting trying to port old hacks to the Touch...

12-18-2011, 06:50 PM	#3
Serpentine Evangelist Posts: 416 Karma: 1045911 Join Date: Sep 2011 Location: Cape Town, South Africa Device: Kindle 3	I wouldn't be surprised if the double height of the Touch virtual res is to do with the touch, either to store an interaction map to map between, for faster key press effects, or as a mask. That said, the padding on that rows and the extra padding might also have something to do with holding touch data, maybe trying to skip bringing things out of a lower state until there's some actual processing to be done. Be interesting to have a look at the mem referenced. Nice info tho.

02-22-2012, 04:33 PM	#6
Ethan G Member Posts: 12 Karma: 10 Join Date: Feb 2012 Device: Kindle NT	hahaha! Thanks for the info, geekmaster. "eips ''" suits me fine.

05-17-2014, 08:45 AM	#9
knc1 Going Viral Posts: 17,212 Karma: 18210809 Join Date: Feb 2012 Location: Central Texas Device: No K1, PW2, KV, KOA	Now that is very strange indeed. Did both xres and yres change?

05-17-2014, 12:54 PM	#11
knc1 Going Viral Posts: 17,212 Karma: 18210809 Join Date: Feb 2012 Location: Central Texas Device: No K1, PW2, KV, KOA	Even the driver name changes.() At least both are 8bpp - but that is about all that is the same. Probably losing the pointer to the correct driver structure when restoring the original orientation (an 'extra' layer of indirection? points at the driver rather than the upper "driver shim"?) - as I recall, the K4 is one that uses some "driver shims" on top of the K3 driver. Or some other weird driver mess. If the K4 was still in production, it might be worth fixing it. [Whoot! 5,900! I gotta get a life.]

05-17-2014, 11:25 PM	#12
Ethan G Member Posts: 12 Karma: 10 Join Date: Feb 2012 Device: Kindle NT	It's a mess one way or another! Still, a mess is what I expect from Linux systems these days. I was happy to see a build environment for static binaries with tcc. I got ideas from your build instructions and set out to try to make a tcc+musl build environment, but before I got very far a friend convinced me to port the 9front fork of the Plan 9 operating system instead. I'm excited and scared, I love 9front but I've never done any driver development before! I won't go into detail here, I'm way off topic already, but I'll post about my progress and my reasons for doing it if and when I get anywhere.

05-18-2014, 08:54 AM	#13
knc1 Going Viral Posts: 17,212 Karma: 18210809 Join Date: Feb 2012 Location: Central Texas Device: No K1, PW2, KV, KOA	I did build the Plan9 kernel module for the Kindles. Never did hear from anyone who tried it.

05-19-2014, 08:08 PM	#14
Ethan G Member Posts: 12 Karma: 10 Join Date: Feb 2012 Device: Kindle NT	I guess that's a typo, because taken at face value, saying "the Plan9 kernel module" is like asking "What version of Windows do you need to run Linux?" Do you mean v9fs, the 9p filesystem module for Linux? Or do you have secret code from the long-forgotten Glendix project?

Advert

Advert