MobileRead Forums - View Single Post

geekmaster · 05-16-2016, 08:55 AM

I tried a number of different bitmasks to get the pixels inside the frambuffer bytes sorted out, so I can draw individual pixels instead of individual bytes as I do in my eink algorithmic art scripts (giving fat pixels on K3 and earlier).

My gmplay video player handles pixel packing correctly on DX/DXG/K3 (which all use Epson Broadsheet eink controllers with two pixels per byte, bitmasks 0xF0 and 0x0F) and correctly for FreeScale SoC embedded eink controllers with one pixel per byte, bitmask 0xFF).

The K1 uses an Apollo eink controller with four pixels per byte. If I use bitmasks 0xC0, 0x30, 0x0C, and 0x03, black areas display as stripes. Likewise, bitmasts 0x03, 0x0C, 0x30, and 0xC0 are also striped. Both sets of bitmasks updated the eink display without flicker at multiple frames per second. I also tried bitmasks 0x05, 0x0A, 0x50, and 0xA0 to see it there was any bit interleaving, but the display updates became full-flash updates, with a much slower framerate (i.e. grayscale pixels). This is mysterious because I got solid black areas when running my "tangle" eink demo script that uses 0xFF and 0x00 for the pixel values (i.e. quad-width pixels). Solid black dithered areas should use the same value. The only difference I can see is that the scripts use the /proc to update the display, which the gmplay C program is using ioctl calls. Perhaps an eink structure misalignment is causing this weirdness (just like the lab126 FUBAR between FW 5.0 and 5.1). Perhaps I just need more coffee to sort this out?

I loaded up the Apollo driver gpl source code (part of the firmware source code from amazon) into my "programmer's editor", and I will grab another coffee and see what I can learn from that code... Sometimes ya just gotta UTSL.

EDIT: I just changed the bitmasks to 0xFF, to force the entire byte to 0x00 or 0xFF depending on the value of every fourth pixel. Now I have solid areas, but only eight shades of dithered gray because of the fat pixels. This shows it is not the eink structures at fault, nor is my code writing to the wrong bytes. There seems to be something funky about pixel pairs. More testing to ensue...

EDIT2: I just tried bitmasks 0xF0 and 0x0F (same as for 4-bit pixels). Solid black areas are striped again, though that could be because of the dithering checkboard pattern being stretched, in this case. However, that does not explain the striping when I use 2-bit pixel bitmasks. I still have Apollo eink secrets to learn, obviously...

EDIT3: I code up a test pattern that overwrites the left 32 bytes (128 pixels). That pattern shows that the pixels are packed exactly as I had first presumed would make the most sense). However, that is what I tried to do in my dithered-bit packing (which is obviously not working). I have examined the code carefully multiple times. This is where another pair of eyes comes in handy. I dislike publishing broken code, but MY eyes are sure not (yet) seeing where I went wrong... I just brewed some more coffee, so I will grab a cup and RE-re-examine my code.

05-16-2016, 08:55 AM	#213
geekmaster Carpe diem, c'est la vie. Posts: 6,433 Karma: 10773670 Join Date: Nov 2011 Location: Multiverse 6627A Device: K1 to PW3	I tried a number of different bitmasks to get the pixels inside the frambuffer bytes sorted out, so I can draw individual pixels instead of individual bytes as I do in my eink algorithmic art scripts (giving fat pixels on K3 and earlier). My gmplay video player handles pixel packing correctly on DX/DXG/K3 (which all use Epson Broadsheet eink controllers with two pixels per byte, bitmasks 0xF0 and 0x0F) and correctly for FreeScale SoC embedded eink controllers with one pixel per byte, bitmask 0xFF). The K1 uses an Apollo eink controller with four pixels per byte. If I use bitmasks 0xC0, 0x30, 0x0C, and 0x03, black areas display as stripes. Likewise, bitmasts 0x03, 0x0C, 0x30, and 0xC0 are also striped. Both sets of bitmasks updated the eink display without flicker at multiple frames per second. I also tried bitmasks 0x05, 0x0A, 0x50, and 0xA0 to see it there was any bit interleaving, but the display updates became full-flash updates, with a much slower framerate (i.e. grayscale pixels). This is mysterious because I got solid black areas when running my "tangle" eink demo script that uses 0xFF and 0x00 for the pixel values (i.e. quad-width pixels). Solid black dithered areas should use the same value. The only difference I can see is that the scripts use the /proc to update the display, which the gmplay C program is using ioctl calls. Perhaps an eink structure misalignment is causing this weirdness (just like the lab126 FUBAR between FW 5.0 and 5.1). Perhaps I just need more coffee to sort this out? I loaded up the Apollo driver gpl source code (part of the firmware source code from amazon) into my "programmer's editor", and I will grab another coffee and see what I can learn from that code... Sometimes ya just gotta UTSL. EDIT: I just changed the bitmasks to 0xFF, to force the entire byte to 0x00 or 0xFF depending on the value of every fourth pixel. Now I have solid areas, but only eight shades of dithered gray because of the fat pixels. This shows it is not the eink structures at fault, nor is my code writing to the wrong bytes. There seems to be something funky about pixel pairs. More testing to ensue... EDIT2: I just tried bitmasks 0xF0 and 0x0F (same as for 4-bit pixels). Solid black areas are striped again, though that could be because of the dithering checkboard pattern being stretched, in this case. However, that does not explain the striping when I use 2-bit pixel bitmasks. I still have Apollo eink secrets to learn, obviously... EDIT3: I code up a test pattern that overwrites the left 32 bytes (128 pixels). That pattern shows that the pixels are packed exactly as I had first presumed would make the most sense). However, that is what I tried to do in my dithered-bit packing (which is obviously not working). I have examined the code carefully multiple times. This is where another pair of eyes comes in handy. I dislike publishing broken code, but MY eyes are sure not (yet) seeing where I went wrong... I just brewed some more coffee, so I will grab a cup and RE-re-examine my code. Last edited by geekmaster; 05-16-2016 at 12:34 PM.