i.MX508 EPD controller interface

[bardo]

Hi,

I am looking for info on the interface to the EPD controller in the Nook Touch and Sony PRS-T1.

Both use the  i.MX508, but seen from the Java interface, use different drivers. The Nook uses separate calls into a N2EpdController function, the Sony adds an updatemode parameter to its display functions. At some point a JNI interface passes the control to the kernel.

Does anyone know if there is a standard way/code available to steer the EPD controller in the  i.MX508?

If the makers of eReaders also modify the kernel, I think the case is lost, otherwise there would be a possibility to write a common Java interface for eReaders using this chip family.

With your information, you could bring e-ink a step further by assisting app developers with suitable WebKit/WebView classes.

KR Bardo

[DannyNold]

Does the Nook even use the i.MX508?  I believe the i.MX508 is used in the Sony Reader, but of course if the underlying HW is not all i.MX508, then you aren't going to be able to align on a common low-level API without adding an additional wrapper layer around the framebuffer drivers.

Assuming that you can align on a common EPD driver API, then I think the app-level code should be able to run on both.  This is all pretty speculative, given my lack of understanding of what is going on in the UI layers of both the Sony and Nook e-readers.

Thanks,

Danny

[bardo]

Hi Danny,

thanks for the info.  Simpler than the region dependent updates, I am interested in control of the updatemode (A2, G16, ..).

Would it be possible to write a (application side) Java code for the i.MX508 EPD that is operational on the Nook and the Sony? I understand this implies that the firmware side of both devices offers the same interface. Please correct me if I am wrong.

If so, could you provide documentation?

Thx, Bardo

[DannyNold]

Hi Bardo,

I can provide info on the low-level interface to the EPD controller, but I can't say a whole lot about how various e-readers are hooking in to this low-level API through their various UI graphics layers.

The basic concept is that updates to the content of the frame buffer must be accompanied with an invocation of the MXCFB_SEND_UPDATE API ioctl extension.  This tells the EPD controller about the precise region that requires an update on the EPD panel.  To achieve this, the UI must exert tight control over any graphics updates to the framebuffer.  There are a few additional APIs to do things like synchronize with the completion of any given EPD update, or to set or change the mapping of waveform modes used in the EPDC driver.

Hopefully this helps provide some of the kind of information you are seeking about the low-level interface.

Thanks,

Danny

[bardo]

No answers?

Who can provide infos on a low-level EPD (e-ink screen) driver?