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.
*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.
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 monitors on the market today typically offer the following modes:
The modes in the market today have several issues:
The entire presentation latency can be broken down into parts:
To solve these issues, we have the following proposed solutions.
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.
To optimize the latency, we implemented the following measures:
With these measures combined, our controller achieves:
a consistent < 120ms latency, compared to competitors, up to 270ms latency.
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.
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.
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.
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
The Modos Team