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.