Challenges Building an Open-Source E Ink Laptop
alexsoto.dev
alexsoto.dev
From the day-to-day conversations with community members from EI2030, we've identified some challenges with building an eink laptop.
We've decided to write an article to introduce EI2030, discuss the challenges of building an open-source eink laptop, and hear from others.
If you have any questions, comments, or feedback, please feel free to reach out.
We would be interested in an e-Ink experiment. During the initial prototyping this was one of the options we considered, but back then it would have been prohibitively expensive and we decided to focus on an IPS display and to get to ship a viable product as quickly as possible -- with a tiny team.
Adapting an e-Ink display to MNT Reform would mostly be about designing/adapting the screen housing and introducing a signal path to an e-Ink driver: options could be MIPI-DSI, eDP, USB, or SPI, for example.
Edit: My email is lukas@mntre.com if you want to get in touch directly. We also have a community over here: https://community.mnt.re/
Hello Lukas,
I will say MNT reform was probably the best shot at "artisanal laptop" I've ever seen.
It's a good, good balance on ones ambitions, and reasonable expectations of what a small team can manufacture, while still feeling very unique, and original.
Massive component shortages are a life, and death matter for small companies now, and it's not only about IC shortage.
What we had in the industry for last 5-6 year is a chronic shortages, and interruptions of supplies of passives for example.
Redesigning entire power supply circuit, and re-layouting the PCB because one can't find a high spec capacitor? Happened many times on my watch.
Doing design is only like 10% of time one spends to manufacture anything, and because of that it's not rational to obsess over it.
For an enthusiast team, just getting anything, even a prototype run coming out of a factory is where 9 out of 10 projects stall.
People run out of the financial runway thinking the factory gate being the finish point... and then they get an email like "Please redesign all your design, and do it 1 week or loose the manufacturing time slot"
Either you have lots of trial, and error yourself, or you pay somebody for a bit less of it, but still nowhere near a complete assurance.
An experienced contractor may keep burning your money, but deliver something in the end.
If you yourself is not confident in your experience, there is a risk your team just running out of enthusiasm, and patience, if not money without seeing the light in the end of the tunnel.
At every scale changes to the design (either for enhancements or EOL parts) is expensive. Injection molding dies require significant engineering, setup, and futzing-with to bring to production. More recent innovations in mfr'ing can be helpful (speed up prototyping and lower the cost of spinning molds or dies) but can't completely liberate you from the difficulties.
I would love to see stuff like this succeed, but the difficulty can't be underestimated.
Please consider using IRC or Matrix.
Zulip Server: https://ei2030.zulipchat.com/register/
Can you say why?
The benefits that led this project to choose an open source approach applies to other domains as well. If they believe in those merits, then they should naturally be apparent in the other systems that they would rely on, such as their collaboration tools. If you want the advantages of open source to proliferate, you have to cast your lot with more open source tools. They're equally suited to the task as, say, Discord.
Choosing proprietary tools and platforms can also easily serve to reduce your pool of potential contributors who don't want to use proprietary tools, and especially those who don't want to install proprietary software on their own computers, like the Discord client.
Some people simply cannot use something like Discord at all - it has a high hardware requirements floor, poor to mediocre Linux support and completely absent support for systems like BSD, not to mention grave accessibility problems. Only an open protocol enables anyone to build the clients that suit their needs, and are not dependent on the whims of some corporate board of director's determination of your merit (i.e. financial exploitability) as a participant.
Why would you specifically want proprietary software?
Forcing yourself to use a bad piece of software on ideological grounds, or worse still, engaging in doublethink (deluding yourself that it's actually a good piece of software and that everyone else is mistaken) does not help the open source movement. It damages it.
Exactly this. It reminds me of the worst type of Apple fans, when people try to argue that a piece-of-crap software provides an equal experience to a ridiculously polished piece of proprietary software. Sometimes open-source has better software, but sometimes it doesn't and there's nothing worse than being gaslit by zealots.
This might be true of Discord, which I guess is an Electron App, and is a strong reason to eschew Elecron (which ironically is open source), but it’s pretty hard to claim accessibility as a win for open source with a straight face.
> Only an open protocol enables anyone to build the clients that suit their needs, and are not dependent on the whims of some corporate board of director's determination of your merit (i.e. financial exploitability) as a participant.
This doesn’t really seem true at all. An open protocol is necessary but very far from sufficient.
In order to build and maintain software, you need hardware, expertise, and time, and often it is simply impossible to do alone.
These cost money, and getting this money means someone determines your merit, in the case of open source development that is in fact typically although not exclusively corporate boards.
I’d like what you are saying to be true, but it just doesn’t seem to be in our current world.
I take it as an expression of an unproven ideal.
- Some usb devices: keyboard, touchpad, camera and internal usb hub for additional devices and external ports.
- HDMI screen with amplified speakers.
- Battery charger and internal power source for internal devices.
- Internal space for HD, SSD, eMMC, WiFi antenna adapter and most common ARM SBCs.
[0] https://www.elecrow.com/crowpi2-raspberry-pi-portable-laptop...
IMHO it's a brilliant idea hobbled by bad thermals and not quite enough pins.
I understand that the Raspi form factor is not the most adequate for a laptop, but it is a very common form factor. Anything else doesn't even comes close to its popularity. So I think we have to adopt what we have. The only other possibility I can think of is the 96boards standard.
>SBCs are not really a good fit for laptops in my opinion because you have to adapt everything with individual cables that are meant for external use
The CrowPi2 seems to work well around that. Never seen one personally but it seems good enough for me.
>are there any SBCs you would like to use except for the Raspberry Pi?
Yes. I want to use a Rock-Pi-4. AFAIK it is the only ARM SBC that is 100% functional without any proprietary blob.
Just imagine, you could keep using your laptop for decades upon decades! Your upgrade is just swapping out the mini-PC inside it.
I wonder if using an eink display as a detachable auxiliary display to show static data such as calendars, todo lists, chats and system monitoring would be more useful.
1. There is such thing as an e-ink screen that doesn't hold its image (and that the fastest-refreshing screens in R&D are this type). In other words, beware if someone says "this e-ink screen can refresh at 60FPS" as it might have sacrificed its power usage in order to achieve this (those screens are still useful if you only care about eyestrain/sunlight readability though). 2. 'Good Ereader' makes all his money selling the devices he reviews, which is a HUGE conflict of interest, AND HE IS NOT TRANSPARENT ABOUT THIS. Seriously, the dude generally either mentions it at the end of the video/article or not at all. Usually not at all. That's super scummy, and as such you shouldn't trust him or his videos. 3. Note that technically fast-refresh mode isn't getting 20 frames so much as refreshing a fraction of the screen at a time, so you have 10 pixels at 2Hz rather than each pixel refreshing at 20Hz. You could call it an interlaced refresh or dithered refresh, I'm not sure what the exact technical term is. The reason this matters is that we can't actually make electrophoretic pixels refresh any faster and they probably won't ever refresh the same pixel repeatedly at e.g. 60Hz - you're working against physics when you're shaking your ink up and down that fast, and you're talking about at least an order of magnitude more than you're getting right now.
For console work, the ghosting is acceptable. For full-screen GUI, it would likely become distracting if windows are moved frequently or contain animated graphics. For reading text, the quality of e-Ink displays is excellent. And outdoor visibility is incorrectly discounted in the article.
As a standalone display, such as you describe, e-Ink should be quite well suited.
We reached 210+ Discord members today.
For years when discussing displays and computing ergonomics, I've claimed that I look forward to the day when my screen doesn't need to emit light, and maybe using it can feel more like paper.
Reading this makes it seem less sci-fi future, and possible today if we can get enough interest/momentum.
I'm trying to think of practical places to start for a sellable product. I love the Paperterm idea, but recognize that it's super niche. Maybe something focused on distraction-free writing?
Honestly if Feedly or a similar RSS reader came out with a dedicated eink reader it'd probably be a day one purchase for me, but maybe I'm in the minority.
Highly recommend it. I consider it a breakthrough tool for thought.
Wow, thanks for the heads-up that they actually released this! I backed their Kickstarter a few years ago (which didn't raise enough money), but you'd think they'd send an update after releasing the actual device.
-Writers -Coders/Terminal Users like sysadmins -DIY/Hardware Hackers/Raspberry PI/ESP32/Cyberdeck folks -Productivity Hackers -Health Tech folks -Gadget Lovers -Limited Functionality Devices for Education -Folks with medical pre-conditions who need to use eink (e.g. https://dasung-tech.myshopify.com/blogs/news/how-dasungs-e-i...)
I think there is a market, I am just surprised that we take usual monitor like eye-strain as well as the blue light for granted and haven't done anything against it for years. Even though we are having more display usage than ever.
Plenty of us around here basically live in the terminal and if such a device existed at a reasonable price, I think uptake would be pretty good. It presents itself as a tool, not a do-everything panacea. It could be extended in small ways to fit the distraction-free-writing crowd and the like without compromising on its killer features. Basically a tool for a few niches--sysadmins/devops, developers, embedded device communications, distraction-free writing. Put a good terminal-based browser on a server (e.g., further develop brow.sh) and it opens up a huge number of other niches.
> f you want to use the nice partial refresh waveform, the open source aspect of this is going to run face first into secrecy requirements. The company selling you the display controller may be willing to build you an out of tree kernel module, and you can totally figure out what it does, but it won't be open source at that point.
I'm sorry but you're making rather clearly incorrect statements which makes me suspicious of the veracity of your other comments. I'm quite familiar with their current and past technologies. You used the term "Partial refresh waveform". First of all, E Ink's active matrix electrophoretic displays like the ones in the Kindle don't need to be refreshed. That's a fundamental property. Secondly, in case you meant "partial update", that's a property of the display controller, not of the waveform. You can google this and easily see that it in fact open source and commonly utilized. https://github.com/UDOOboard/Kernel_Unico/blob/master/driver... . Most modern EPDC even the hardware ones contain that feature and it is exposed as open source.
> run face first into secrecy requirements.
I'd like to see an elaboration of your claims. Please share what evidence you have about all this "secrecy". I work in the display industry, not for E Ink, and I've never heard of these things going on so it would be quite interesting for me to learn about it.
There is a waveform that specifically maintains image quality over many partial refreshes. (Interestingly it only works for black text on white backgrounds, and not the other way around, though I'd hope they would have fixed that by now.) It required quite a bit of pre-processing before you slam the frame buffers into the hardware. That logic came to us as a pre-baked kernel module from our hardware vendor, and EIH did not want us to know what was in it, though it wasn't too hard for us to figure out what it did.
And, to some extent, you can just say screw them, I'm making my own waveforms. However, a junk waveform can damage the display if they aren't correctly built to prevent static charge build up. Also, each batch of displays comes out different enough that EIH provides slightly tuned versions of the waveform on a per batch basis. I'm not sure how well the open source model will work when people don't have equivalent hardware. If someone is tuning the waveforms for their panel, that may not work for all users.
The static build up is interesting. I've seen pictures return to the display minutes after it was cleared to white because the charge built up on the display was still affecting the pigments. Never seen a display break due to it, but it was described to us as a theoretical possibility if a waveform wasn't roughly balanced in its actions.
Do I get my nerd cred now? Have I satisfied you, all knowing hacker news poster?
No, you have fundamental errors in your understanding of how electrophoretic displays work. That's not how waveforms work. You're confusing refresh with REAGL. Since you have some kind of attitude issue, I guess no further beneficial discussion is possible.
> That logic came to us as a pre-baked kernel module from our hardware vendor, and EIH did not want us to know what was in it, though it wasn't too hard for us to figure out what it did.
Evidence free comments don't strengthen a claim.
I’m super eager to get one but most are either terribly small or prohibitively expensive.
I’m a sound designer. I just need to see the meters bouncing in my DAW and a reasonably updating zoom function and mouse movement. I dont need awesome fps and i dont need amazing colors. I think there’s an abundance of similar professionals. E-ink is not just for writers and coders as many seem to claim :)
Despite looking plausible, I think it would actually end up more straining on the eyes than just an lcd. Maybe in a few years...
Edit: it’s interesting, it looks great when he’s writing on the screen with a stylus. Wonder why a mouse would be so much worse.
Edit 2: this is what a dasung monitor looks like scrolling, mouse cursor etc: https://youtu.be/5pevlmk5kQs?t=655
Mouse requires low latency to be useful as a pointing device. Do the exercise I've outlined in my earlier comment and you'll see for yourself why, really.
That said, this Dasung screen has a really impressive latency for a e-ink screen. DAW work would still be tiring with it, but it feels like it's already unlocking lots of other possibilities (even though those fast modes leave lots of visual artifacts, but that's to be expected).
- A Raspberry Pi
- A keyboard
- A mobile E Ink monitor
- A USB power bar
I imagine the Raspberry and the power bar in a case with two USB ports. Then one cable goes to the monitor and another to the keyboard.
This might have the additional benefit that one can put the monitor on something when working. So it is more ergonomic than looking down to a laptop.
The device comes with SSH enabled by default, with a randomly-generated password in the settings menu. Its main UI is a proprietary app, but there is a vibrant community of open-source "hacks"[2] ranging from binary patches adding features to the stock UI to a fully libre replacement OS based on Parabola[3]. Its USB port works in host mode, so you can plug in a keyboard and use it as a terminal. I've been meaning to make a nice cover for it with a built-in keyboard like the MS Surface devices.
[1]: https://remarkable.com/ [2]: https://github.com/reHackable/awesome-reMarkable [3]: http://www.davisr.me/projects/parabola-rm/
They meaning Remarkable? If so, then that's marketing-speak. The simple truth is that Remarkable's products all use NXP (formerly Freescale) controllers. The Remarkable2 uses i.mx7D. That has a built-in hardware EPDC. You can google it. The driver is open source. https://github.com/UDOOboard/Kernel_Unico/blob/master/driver...
That's what does all the "difficult stuff". Not Remarkable.
> did you know that to flip pixels, e-ink displays require annoyingly proprietary lookup tables of waveforms that can be up to 5-dimensional?
Yes. But you realize tables are each panel specific. Meaning every single panel you see requires a custom waveform. Nowadays they (E Ink and their partners)'re getting better and have some increased level of consistency so some waveforms can achieve the same result on whole batches of panels. But you'll still see it being batch specific. Take a waveform for one batch and try to use it on another and you'll get lousy ghosty results or maybe even damage the panel permanently.
> and worked with E-ink directly to implement said waveform table, very low-latency partial updates, and other e-ink "secrets" that could very well be worked out via reverse engineering but are otherwise under NDA.
That's more marketing speak. If you look at their code which they published, https://github.com/remarkable , it is just minor patches to NXP's driver. All the hard work was done by NXP.
> The driver is open source.
Clearly, or I couldn't be running Linux-libre with it.
why would you think this? Remarkable doesn't generate waveforms and have never claimed that they do.
> it's just they're a Real Company™ who E Ink will talk to, and I am not
You say that as if it is unique to E Ink. Whereas its standard across the entire display industry. Do you think Samsung would talk to you? Do you think LG would talk to you? You have to be, in your words, a real company, someone that offers some value proposition. In fact, thinking about it, that's true throughout the entire tech industry. Nobody talks to someone who isn't going to offer some current or future profit.
I don't know, I probably think a lot of things that are wrong. Up until your last post I assumed the waveforms were provided by E Ink themselves. When you mentioned different panels needing different waveforms I assumed you must have meant per unit, not per model of display, because the latter is obvious. If they were unique per individual display that calibration would need to be done in the factory. Did I misunderstand, and you meant per model of display, and not per unit?
Come to think of this, I can verify this right now. Here are the results of `sha256sum /var/lib/uboot/waveform.bin` on two different Remarkable devices of the same model/SKU:
185515bebf37d3e9d99ffa1f13a2804bbb2b64464fa6fc5067475fb6f65ff6b0 /var/lib/uboot/waveform.bin 185515bebf37d3e9d99ffa1f13a2804bbb2b64464fa6fc5067475fb6f65ff6b0 /var/lib/uboot/waveform.bin
You'll have to take my word I didn't copy the same line twice... but as you can see, they're the same. So I don't necessarily think the waveforms are different per unit or batch.
> You say that as if it is unique to E Ink. Whereas its standard across the entire display industry.
Sure. But I was talking about why I bought a Remarkable instead of building an open source e-ink laptop--certainly not a product with volumes high enough to get any manufacturer to pay attention. Obviously I would have the same problem if I were trying to build a regular laptop with an LCD screen (or modern CPU, or WiFi...). For hobbyist projects you're certainly not getting any support from manufacturers. The best one can hope for is open datasheets/manuals and even that is pretty rare...
I believe you. Maybe they've solved said problems and now have waveforms that work reliably across multiple batches.
But looking at Kindle, you can see there's a different wbf for each panel batch.
root@kindle /]# more /opt/eink/scripts/pvi_barcode_table.txt E0R M01 60 # ED060SC4 E1M M03 60 # ED060SC4H1 E1X M04 60 # ED060SC4H2 E1U M06 60 # ED060SC5 E23 M0B 60 # ED060SC5H1 E22 M0C 60 # ED060SC5H2 E2N M12 60 # ED060SC7 E32 M13 60 # ED060SC7H1 E31 M14 60 # ED060SC7H2 E2R M23 60 # ED060SC5C1 E30 M24 60 # ED060SC7C1 E43 M3D 60 # ED060SC7T1 L01 MA1 60 # LB060S03-RD01 L02 MA2 60 # LB060S03-RD02
E0D M01 97 # ED097OC1 E0X M01 97 # ED097OC1 E2C M0D 97 # ED097OC1H1 E1Y M05 97 # ED097OC1H2 E29 M0E 97 # EF097OC3 E2B M0F 97 # EF097OC3H1 E2A M10 97 # EF097OC3H2 E2S M15 97 # EF097OC4 E33 M16 97 # EF097OC4H1 E34 M17 97 # EF097OC4H2 E35 M20 97 # ED097OC4 E36 M21 97 # ED097OC4H1 E37 M22 97 # ED097OC4H2
[root@kindle scripts]# cd /var/local/eink/panel/ [root@kindle panel]# ls -l ---------- 1 root root 123683 Aug 22 2017 06_05_009a_3c_152131_05_58_00000db2_85_07.wbf -rw-r--r-- 1 root root 1475735 Aug 22 2017 06_05_009a_3c_152131_05_58_00000db2_85_07.wrf -rw-r--r-- 1 root root 42 Aug 22 2017 panel_id -rw-r--r-- 1 root root 5 Aug 22 2017 version
No.
E-ink displays are more efficient because if they refresh e.g. 1 time a minute instead of 60 times a second, then they are refreshing 3600x less often. Even if they took 100x more power per refresh, they'd still end up using 36x less power overall. It gets even nuttier when you go to e.g. refreshing once a day instead of 60Hz (60 * 3600 * 24 = 5 184 000 refreshes, over FIVE MILLION).
Please note that "e-ink" is basically a blanket term and contains a dozen different technologies (although almost all the screens that are actually sold at actual stores are electrophoretic displays), it's basically a genericized term based on E-Ink Corp so anything I say here is a sweeping summary.
Also in e-inks there's a difference between refreshing the entire screen and a part of it, depending on the implementation.
2.5 inch display - $1
6 inch display - $400
12 inch display: $1200
36 inch display: $1400
Pixel density isn't as good as say a nice Kindle, but they are usable. I've played around with one of their 1.5 inch module
You can buy old 6" e-reader panels for ~22+ USD https://www.ebay.com/b/ed060sc4/bn_7024905630
See https://spritesmods.com/?art=einkdisplay for how to drive them.
Sure, you can get a few, but can you get them at this price at volume or will the supply instantly dry up? Are these so cheap because it's old stock, someone got their hands on beyond life span production equipment, there's some special licensing deal with E-Ink ... ? If the price was sustainable, wouldn't everyone use this display? Or is this price what OEMs actually pay for E-Ink displays (seems unlikely)?
ED97 Looks like an ancient Vizplex panel. I would guess 2010s timeframe. Probably fine. Newer EPD controllers are still backward compatible I think.
> Or is this price what OEMs actually pay for E-Ink displays
E Ink is a niche market. In the display industry, anything below 2 million displays per quarter would be considered niche. Amazon is likely the only player in this market that can reach that kind of volume. Their volume is not high enough to justify scaling up a real high volume factory. From what I've heard, E Ink repurposes existing LCD production lines.
Wow!