The Modos Paper Monitor

At Modos, our mission is to help you live a healthy life by creating technology that respects your time, attention, and well-being. We are an open-hardware and open-source company, and are building an ecosystem of devices to re-imagine personal computing and build a collective vision of calm, intentional, and humane technology.

Today, we'd like to introduce the Modos Paper Monitor: an open-hardware standalone portable monitor made for reading and writing, especially for people who need to stare at the display for a long time.

‍

‍

Specifications

1. 13.3” 1600x1200 Eink panel without front lighting
2. DisplayPort 1.2 input, up to 224MP/s with a potential to support 2200x1650 resolution panel at 60Hz
3. MicroUSB power input (consumes 1.5W~2W continuously)
   

*In time, we will offer a single USB Type-C connection from the PC to the monitor for data and power and provide adapter options for machines without Type-C connectivity.

Our Eink monitor and competitors

There is currently no universally good way to drive the screen, this is due to the technical limitations of Eink technology. As a result, different display driving strategies/modes were designed to address different use cases.

Typically on Eink monitors, one would see multiple modes: text mode, graphics mode, video mode, etc.

However, we think the solutions offered by existing Eink monitors have several drawbacks.

Eink modes

Eink monitors on the market today typically offer the following modes:

1. Normal mode: 1-bit + dithering, ~10fps. Dithering range is reduced to produce cleaner white/ black.
2. Video mode: 1-bit + dithering, ~15fps. Contrast ratio is reduced to increase frame rate.
3. Text mode: 1-bit without dithering, ~10fps. Produce cleaner text edges for reading and typing.
4. Slideshow mode: 4-bit (16 level), ~3fps. Offers great image quality, but generally unusable for many applications.

The modes in the market today have several issues:

1. The latency is a bit too high for interactive use, like moving the mouse cursor or picking a word from the input method window if you are typing, for example, Chinese or Japanese.
2. There are essentially no greyscale modes for typing, so texts are not antialiased. The text mode is arguably better than normal / video mode with dithering, but it's aesthetically not pleasing and still difficult to read.
3. All existing products use error-diffusion dithering as they yield the best result for displaying images. However, the downside is that moving objects would introduce transitions on static pixels. For example, if I move the mouse cursor, the entire rectangular region right to and lower than the cursor would need to be updated. In our opinion, this is distracting at the very least.

Latency

The entire presentation latency can be broken down into parts:

1. The PC processes a keystroke and renders the text, and the rendered text is sent to the screen.
2. The screen controller processes the image and issues an update to the Eink panel.
3. The Eink panel responds to the input, and the pixel changes color.

To solve these issues, we have the following proposed solutions.

Competitor's offerings

1. The controller typically runs at 30Hz with a delay between 0-33ms.
2. The controller buffers the entire frame before processing, adding around 33ms delay.
3. A new update couldn’t start until the previous one has finished.

For example: Imagine you type 2 letters, and before the 2nd one is displayed, the controller starts updating the 1st one. Now the controller needs to wait for the first one to finish updating before starting displaying the 2nd one. This introduces a worst-case delay of ~100ms.

Similar to the previous case, if a letter is being typed but then deleted because the current update blocks all pending updates, it won’t erase the letter unless it’s fully displayed.

Our Paper Monitor

To optimize the latency, we implemented the following measures:

1. The controller runs at a 60Hz refresh rate; this means on PC, in the ideal case, the delay is between 0-17ms.
2. The controller only buffers a few pixels before processing, effectively reducing the processing delay to nearly 0.
3. Each pixel has its update timer. Updating the 1st letter wouldn’t block the 2nd letter.
4. Pixel update request supports early abortion: if the input pixel is changed during the update process, it would cancel the current update and recalculate the timer to drive it towards a new value.

With these measures combined, our controller achieves:

a consistent < 120ms latency, compared to competitors, up to 270ms latency.

Grayscale

We don’t have a universal solution for the grayscale issue that works for all. We do have a simple solution that works for typing.

The display is always refreshed to 1-bit mode first, then drives to 2-bit / 4-level greyscale after a preset time (for example, around 200ms). The process is non-flashing. This allows smooth typing while maintaining greyscale antialiasing for texts on the screen.

We are also planning to implement a 16-level greyscale mode with similar logic, but the 16-level will be flashing. Flashing/ flickering causes distraction and won’t work well for typing, but it could be useful for reading.

For the error-diffusion issue, we are evaluating using simpler dithering methods such as patterned dithering that would generate an image with arguably worse quality but could be more pleasant / causes less distraction when in typical desktop use.

Color

In the future, we would also love to explore options of using color screens. There are two major methods of generating color on Eink and similar screens.

One is to use an RGB color filter array (CFA) in front of a monochrome panel to create color, similar to a color LCD. This allows the same driving logic for monochrome panels to carry over and would have similar response time/refresh rate/ghosting characteristics. The major drawback is the screen would be much darker, as the CFA only allows the light of certain colors to pass through.

Another is to use CMY color pigments inside a single pixel (called ACeP), similar to a color print. This results in much-improved reflectivity compared to CFA solutions, but the downside is increased response time, up to 30 seconds on 1st generation ACeP screens and 1 second on 2nd generation ACeP screens.

On paper, neither of the two technologies is suitable or ready for use on a monitor. If we can acquire screen samples, we might be able to do some testing and maybe provide a color option for purchase for those who do need color.

Native e-ink optimized applications

We would also like to develop a protocol for applications to send hints across the window compositor to the screen controller to change the modes based on the use. This is possible and used on eReaders, so texts, images, and UI elements could use different update modes, but not with the current available Eink monitor + software stack. Our controller supports per-pixel update mode settings, but this would need support from the software side.

Community Survey and Pilot Program

We are in the process of securing funding for our pilot program, building prototypes for its participants, and continuing the work needed to bring devices like our Paper Monitor to the market. We need your support and want to hear from you.

If you believe in our mission of building technology that respects your time, attention, and well-being, please fill out our community survey and apply for our community pilot program to help us make this a reality.‍

We need at least 50,000 people interested in purchasing our Paper Laptop, Paper Monitor, Development board, and future devices we have planned for the ecosystem.

- Participate in our Community Survey

- Apply for Community Pilot Program

‍

Follow our progress on RSS, Github, Matrix, Mastodon, and Twitter, or Get in touch with us.

‍

Join the discussion on our Zulip

‍

Regards,
The Modos Team