|
Solved.
I found (via google translate) a russian site where they discuss the chinese firmware you mentioned, kartu. They do manage to figure out some of the protocol used by the actual hardware device, but it's a bit wobbly.
First, the quick answer to my question: what was wrong? Simply writing to the framebuffer won't do anything on these kinds of devices. You need to tell them to sync the memory with the display.
Fortunately, I've found that there is a driver in linux (at least the one on the sony website) that handles the vizplex screens like the ones in the PRS600. It's called "broadsheet". Looking at broadsheet.c, I looked at their ioctl handling code, then at the available commands in broadsheet.h. Stuff like FBIO_EINK_UPDATE_PIC looked very promising, so I started playing around with that.
Unfortunately, every time I tried to paint something to the screen using an ioctl, I'd freeze my reader, requiring a hard reset with the stylus and magic button. Google doesn't help; there appear to be no matches of anyone actually *using* that driver, only some politics about accepting it into the linux kernel.
After hitting my head against the wall, I checked the power status of the display. I'd just assumed it would be POWER_MODE_NORMAL as it just got updated a second ago. Nope, it was POWER_MODE_SLEEP. Changing the power mode to POWER_MODE_NORMAL made the screen updates actually go through instead of freezing the reader.
The driver is kinda undocumented though... updating using upmode=0 causes some strange flashing and only some shades to come through; upmode=1 has a few shades come through (transparency?), but no flashing. Modes 2 and 3 seem to allow all shades to come through, but mode 3 apparently updates the entire screen, not just a partial update.
Anyway, code attached. I'm just drawing the test pattern in the first post of this thread, but now at least it works.
Code and binary attached.
|