The familiar CRT monitors or backlit LCD screens on our desks continuously consume power in order to hold an image. Electronic paper (e-paper) is different: power is only needed to change the image. Just like paper, e-paper is able to hold the image permanently without consuming any power. Displays using CRT, backlit LCD, plasma and OLED technologies are all emissive, meaning that they have to produce the photons that reach the eye. This implies that they have to compete in brightness with ambient lighting, which can result in eye strain. E-paper is the opposite: it is reflective, which makes it possible to read the display using ambient light even in the brightness of a hot sunny day.

E-paper is referred to as a bistable or non-volatile technology because of its ability to hold a specific pixel state without power. There are several variations of e-paper; they differ in terms of which physical mechanism is used to achieve the non-volatility of the display. These mechanisms include interferometric modulation, bi-stable twisted nematic liquid crystal [PDF], cholesteric liquid crystal, and electrophoretic phenomena.

Interferometric modulation uses the same principle of light wave interference that results in the rainbow of colors seen with oil floating on water. Control of wave interference through bi-stable or multi-stable micro-electro-mechanical systems (MEMS) is what enables electronic control of the color of a pixel.

In standard twisted nematic liquid crystal displays (TNLCD), the liquid crystal is sandwiched between two rubbed polymer orthogonal alignment layers. Bi-stable twisted nematic implementations such as Zenithal liquid crystal replace the first or both alignment layers in favour of a sub-micron relief profile that weakens anchoring to the surface and makes it possible to latch various stable orientations of a liquid crystal pixel using electrical pulses.

Cholesteric liquid crystal provides the ability to selectively reflect various ranges of wavelengths of visible light based on the pitch of the liquid crystal. The pitch can then be electronically controlled to set various pixel states.

Electrophoresis describes the fact that particles within a fluid can be kinetically affected by an electrical field. Basically, applying a voltage pulse causes pigment particles within a solvent solution to move. This concept is what is used to control whether a pixel appears black, white or a shade of gray. This article will focus on electrophoretic displays since they are relatively easy to obtain.

Controllers

Traditional display controllers are interfaced to the host using a bus such as PCI Express or AGP. These controllers have local framebuffer memory or sufficient internal line buffering to utilize shared host memory; they expose their framebuffers through memory mappable regions. Display servers like Xorg or Xfbdev that utilize the kernel's fbdev interface expect to be able to mmap() the device framebuffer. The implication is that a driver that implemented only write()/seek() access to the framebuffer would have limited usage.

Electrophoretic displays require specialized controllers that are capable of driving suitable waveforms in order to control the display media. This is because of subtle issues around the behavior of pigment particles within a solvent. The controller must drive waveforms that result in fast, reproducible and optimal movement of pigment particles. These waveforms are a key factor in minimizing pixel update latency, achieving good contrast and reducing ghosting effects in the output image. Currently, electrophoretic display updates are significantly slower than CRT or LCD display updates. For example, a grayscale update of E-Ink's most recent Vizplex display material can take up to 740ms. This latency has an effect on how hardware is interfaced with electrophoretic display controllers and how software should then interact with the display.

One of the electrophoretic display controllers for which Linux support has been posted (tarball) is a controller from E-Ink called Apollo. This controller is interfaced to the host through 8-bit data and 6-bit control over General Purpose IO (GPIO) interfaces. The implication of the use of GPIO is that it is not a memory mappable interface. Each pixel of the framebuffer has to be wiggled to the controller by turning individual GPIO lines on and off. Display updates on the Apollo with an E-Ink 6" panel with a resolution of 800x600 and 2 bits of grayscale require between 500ms - 1200ms. Given this set of circumstances, it would have been an option to implement a userspace library or support code that performed the GPIO wiggling. However, such an implementation would forfeit support from Xfbdev and other common fbdev compatible applications.