Challenges Building an Open-Source E Ink Laptop(alexsoto.dev)
alexsoto.dev
Challenges Building an Open-Source E Ink Laptop
https://alexsoto.dev/challenges-building-an-open-source-eink-laptop.html
104 comments
Hi, I'm the project lead of MNT Reform, an open hardware laptop that just started shipping (link: https://www.crowdsupply.com/mnt/reform)!
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 [email protected] if you want to get in touch directly. We also have a community over here: https://community.mnt.re/
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 [email protected] if you want to get in touch directly. We also have a community over here: https://community.mnt.re/
I just want to say that I love your work! I have been following on Mastodon and watching the MNT Reform project with considerable interest, and the possibility of an E-Ink option really helps sweeten the pot. At this point I'm pretty certain I want my next new laptop to be a Reform.
+1
Wow, such people here.
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.
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.
Hey Lukas,
Thank you for your comment and for reaching out. I'm a big fan of MNT Reform, and it's great to hear of your interest in doing an e-ink experiment. We are interested. I'll send you an email later today to talk further.
This is awesome! As someone with a Reform on the way, I'd be very interested in a conversion kit to install a daylight-readable display. :)
I feel the project outline is very idealised, without any much regard to how manufacturing will be done.
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"
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"
Thank you for your feedback. I agree with your points; manufacturing is an essential part of the process that I neglected to include in the article. Thank you for bringing it up. When we are at that stage, I would appreciate your feedback and suggestions.
Can only tell there is no easy way.
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.
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.
Yeah,the technical challenge of getting something working usually end up being the easier part. Manufacturing ends up being very difficult: at a small scale, it's super expensive and at a medium to large scale, logistics becomes difficult.
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.
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.
Hi Alex! Please, please, please do not use Discord to organize your open source project's community. Open source projects should rely on open source infrastructure. Discord is a proprietary platform, with a proprietary client, using a proprietary protocol, and has no business being involved in FOSS projects.
Please consider using IRC or Matrix.
Please consider using IRC or Matrix.
Hi, we are working on setting up a Matrix server with bridges to other platforms. If you have suggestions or experience in this, I would appreciate your support.
Imho, the best chat platform is Zulip. It has channels, named threads, good search, and persistent history. It's also open source. IME, it's way better for communities than Discord, IRC, Slack.
I've seen Zulip in action and think it's great. I also think Element.io can be helpful (for Matrix)
I don't have any specific experience with Matrix to share suggestions from, unfortunately. But that's a good solution! Thanks for looking into it.
Hi ddevault, We've created a Zulip server and will be transitioning away from Discord.
Zulip Server: https://ei2030.zulipchat.com/register/
Zulip Server: https://ei2030.zulipchat.com/register/
Awesome! Thanks!
> Open source projects should rely on open source infrastructure.
Can you say why?
Can you say why?
It seems tautologically obvious, but I can elaborate anyway.
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.
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.
As an open source developer I use some tools that are not open source, and which I would not even want to be open source. It doesn’t have to be an ideological battle. It’s just different distribution models with different benefits.
> I use some tools that are not open source, and which I would not even want to be open source.
Why would you specifically want proprietary software?
Why would you specifically want proprietary software?
I generally prefer open source over proprietary, all else being equal. But there are some software categories where the best OSS examples are still leagues below the best proprietary examples in design and quality, despite many OSS attempts over many years. In such categories, I'd love it if a seriously competitive OSS example emerged, and I'd probably jump on it and start evangelising it. But until that happens, I have to assume there's something about the proprietary model that just works better to produce high quality software in that particular category.
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.
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.
>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.
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.
> not to mention grave accessibility problems.
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.
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.
Mako Hill covered this in his essay entitled "Free Software needs Free Tools":
https://mako.cc/writing/hill-free_tools.html
https://mako.cc/writing/hill-free_tools.html
What I'd love: a common chassis that includes:
[0] https://www.elecrow.com/crowpi2-raspberry-pi-portable-laptop...
- 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...
I am thinking to adopt a SOM standard like Qseven or COMExpress etc. in the (a bit more far) future. What do you think about that? 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. And: are there any SBCs you would like to use except for the Raspberry Pi?
>What do you think about that?
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.
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.
I think the same is true for the Rock64 from Pine64 and the Libre Computer Board ROC-RK3328-CC. And probably others based on the Rockchip SOCs.
EOMA68 is/was another attempt at this concept, and worth looking into the challenges they faced and addressed.
IMHO it's a brilliant idea hobbled by bad thermals and not quite enough pins.
IMHO it's a brilliant idea hobbled by bad thermals and not quite enough pins.
Qseven won't get you much in terms of performance, neither in available CPU/GPU nor in features (only 4 x1 PCIe lanes)... if you want actual beasts go for Comexpress Type 6 (or, if you're willing to deal with embedding a GPU yourself and need more PCIe lanes, Type 7) but be prepared the connectors aren't cheap, the standard isn't open (although there are some copies floating around on the 'net) and routing all the high frequency stuff is a pain that requires at least three if not four layers.
The MNT Reform motherboard has 6 layers, which I consider a small number. Also, I was thinking about adopting MXM for a GPU slot.
I'd like that too, but I'd want enough space to fit one of those Atom mini-PCs into it.
Just imagine, you could keep using your laptop for decades upon decades! Your upgrade is just swapping out the mini-PC inside it.
Just imagine, you could keep using your laptop for decades upon decades! Your upgrade is just swapping out the mini-PC inside it.
Is the display fast enough to be used as a laptop?
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.
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.
Dasung makes e-ink monitors and it looks like they can get something like 20 fps, which is pretty good. Probably just enough to use a mouse without going mad. Maybe.
https://youtu.be/AeC3LIFTaho?t=208
https://youtu.be/AeC3LIFTaho?t=208
Please note that:
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.
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.
Using a Mobius e-Ink device, a bigger issue is the ghosting. The discussion of RLCD with up to 60 fps refresh is interesting.
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.
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.
How do you know you are succeeding?
i guess it depends on how you define succeeding:)
We reached 210+ Discord members today.
We reached 210+ Discord members today.
This is great!
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?
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?
I'd love to see some cross between a Kindle and iPad..something focused on reading, but not necessarily books. At night I tend to browse various sites ranging from WaPo, Defector, The Athletic, and New Yorker, and others on my RSS feed and if I could do so on a simple eink tablet I'd probably reach for that more often than my phone or laptop.
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.
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.
Is the reMarkable 2 tablet not a fit for that? Haven’t tried it myself so not sure what its limitations are.
Yes. I got a reMarkable 2 recently and use it all the time. Mostly for note taking and thinking, but recently to read PDFs as well. ePubs are next. And I'm exploring ways to read RSS feeds/blogs on there too.
Highly recommend it. I consider it a breakthrough tool for thought.
Highly recommend it. I consider it a breakthrough tool for thought.
That describes Onyx Boox products to a tee. Full android devices with e-ink screens.
Hi jrrr! I am co-developer of PaperTerm- I agree it is very niche right now. The Pomera DM30 is a distraction free typewriter- it is relatively new (there is also much older options like the AlphaSmart Neo2)- I hope to develop something similar to that with a laptop and some more office apps. I also research solar power managers, as the low power is definitely feasible with e-ink.
> Pomera DM30
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.
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.
There is also https://getfreewrite.com.
That's a good point, what is the first adressable market for such a product to gain first momentum before it can become mainstream. Those seem to be low hanging fruits:
-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.
-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.
Yes, PaperTerm is niche, but the more you look around, the more you see people suggesting a portable terminal-only device, so I don't think the niche is all too tiny. The e-ink screen and battery life are the killer features.
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.
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.
Actually, PaperTerm + offline eBook and PDF reader would be a great compromise. It can be useful when you're connected and when you're not.
From what I've seen working on an e-reader, a big problem for any open source e ink product is the things EIH wants to keep secret about their displays. If 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.
> From what I've seen working on an e-reader,
> 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.
> 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.
Refresh, as in transitioning from one image to another on the display. Partial refresh as in not running the waveform on pixels that don't change color, which dramatically reduces the visual noise for the user. The problem with partial refreshes is the accumulated errors on pixels, and the effects of updating a pixel on the neighboring pixels. The longer you go between full refreshes, the more ghosted cruft you end up with on screen.
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?
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?
> 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.
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.
Is it possible that an e-ink monitor could be an incidental offspring product of this project?
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 :)
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 :)
That's a rather poor use case for e-ink screens. Bouncing meters would be pretty confusing when they blink between white and black while being updated (and an LCD would likely consume less power for that anyway), and mouse movement is pretty much the worst thing to handle for e-ink screens. I'd say that this use case is on the opposite end of usefulness spectrum for those screens than writing text or coding.
Ah, the refresh rate is that bad? I recently watched the preview video for dasungs new monitor and was hoping we’d be there soon https://www.youtube.com/watch?v=RRvlJ2HjH30
While that is certainly impressive, try writing a simple app that hides the system cursor and renders its own one with such low FPS - you'll get tired of it very quickly (and I'm sure all game developers out there will agree without second thoughts :)). It may be good for occasionally clicking something to change the screen, but surely not for working with mouse in a DAW. You'll even have troubles with accurate targeting unless you move really slowly.
Yeah, just saw someone playing call of duty on e-ink: https://www.youtube.com/watch?v=2RQFYVfIgz0
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
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
It's simple - writing on the screen with a stylus is a perfect use case for e-ink screen because the latency doesn't really matter that much (I mean, the threshold where it becomes unacceptable is much higher) and you're just drawing on the screen as opposed to moving something that was already drawn there. I have played with simple drawing apps on a jailbroken Kindle many years ago.
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).
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).
I wonder if it would be possible to build a "Mobile outdoor e-ink workstation" by combining some of the shelf components:
- 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.
- 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 Raspberry Pi may be a poor choice as it does not support power management; there are other SBCs which would get significantly improved battery life when not at 100% utilization, with similar performance.
I just want a kindle with a much larger screen. I don't care how thick or heavy it is. I would just buy a Sony if the software was better.
IIRC pine64 aim to provide an e-ink display to accompany their next SBC.
Direct invite link to EI2030 community discord for anyone that doesn't want to search: https://discord.gg/nnxKnxh
I have thought about building an E-ink laptop for a long time but eventually I bit the bullet and bought a reMarkable[1]. They've figured out all the difficult stuff about e-ink (did you know that to flip pixels, e-ink displays require annoyingly proprietary lookup tables of waveforms that can be up to 5-dimensional?) 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. The device is also very thin, if you care about that sort of thing. The main downside is the hardware is closed source (and rather expensive, but any e-ink product not made of recycled Kindles will be).
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/
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've figured out all the difficult stuff about e-ink
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.
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.
I suppose instead of "difficult stuff" what I should have said is "they signed E Ink's NDA and thus have access to whatever tool they use to generate waveforms, panel-specific or no." I don't mean to heap credit on Remarkable, it's just they're a Real Company™ who E Ink will talk to, and I am not. Frankly I consider getting a waveform that doesn't look bad or cause burn-in over time a more difficult achievement than an open source driver or a hardware e-ink driver (indeed, lots of SoCs have them). Hence '"secrets" that could very well be worked out via reverse engineering but are otherwise under NDA.'
> The driver is open source.
Clearly, or I couldn't be running Linux-libre with it.
> The driver is open source.
Clearly, or I couldn't be running Linux-libre with it.
> they signed E Ink's NDA and thus have access to whatever tool they use to generate waveforms, panel-specific or no
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.
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.
> why would you think this?
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 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...
> 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.
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
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
I heard e-ink displays use virtually no power except when they are refreshing. Say you’re running an e-ink display that refreshes 60 times per second, is it still significantly more energy efficient than an LCD?
>Say you’re running an e-ink display that refreshes 60 times per second, is it still significantly more energy efficient than an LCD?
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.
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.
Refresh rate on e-ink displays is still nowhere near 60x/second, so we can only guess.
Also in e-inks there's a difference between refreshing the entire screen and a part of it, depending on the implementation.
Also in e-inks there's a difference between refreshing the entire screen and a part of it, depending on the implementation.
A friend and I have had somewhat concrete plans for a Linux (Pine64 SOPINE SoM) based e-Ink tablet for a while, but aren't as involved in supply chain stuff. Are the prices you get for orders of new screens in the same ball park as the old Kindle DX display stock? Are my fears that supply will dry up soon (in part due to new popularity) unfounded?
I've been trying to do some E-Ink stuff lately and prices seem to get higher the bigger you go and then drop off. Maybe I'm looking in the wrong places, but my experience is something like:
2.5 inch display - $1
6 inch display - $400
12 inch display: $1200
36 inch display: $1400
2.5 inch display - $1
6 inch display - $400
12 inch display: $1200
36 inch display: $1400
Huh, the display I'm referring to seems to be less well known than I had thought. At the risk of accelerating its popularity gain: I'm talking about the 9.7" ED097OC1, which costs about 30$. (https://www.aliexpress.com/item/33007519185.html).
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)?
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)?
> Are these so cheap because it's old stock
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.
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.
Waveshare sells 1 to 13-inch panels for 7 to 540 USD:
https://www.waveshare.com/product/displays/e-paper.htm
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.
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.
Indeed and the biggest one is in fact much cheaper than 540USD (more like 180). The 540 is HDMI based.
Oh the e-reader panels and that link are a godsend. Thank you!
I've been looking for a good color e-Ink picture frame with WiFi to hack on. It seems like with component shortages this would not be possible with my target price point of $200?
AFAIK Inkplate (https://inkplate.io/) is supposed to get a color version later this year.
I’m looking forward to the day we get 60Hz and 120Hz e-ink panels.
A mouse based interface is a non-starter for sure.
E Ink can do 15-30 Hz refresh rates as long as you are only updating a small portion of the screen every frame.
There's a company called Dasung which sells eink computer monitors that refresh fast enough for full-screen video playback: https://youtu.be/AeC3LIFTaho?t=249
$1000+ price tag O-o -- Hopefully there will be enough demand to eventually make e-ink monitors mainstream so we can see the prices come down
Yes, please! (I just want any laptop that lets me actually use it outside and not be priced ridiculously.)
I'd have no problem paying 1500$ for this. As many of us age , EInk feels much better to read.
Is that a solar panel on top? Can it power the computer?
Hi, neolog! I lead the solar/low-power OS group. The picture in the article is from a Samsung NC215S from 2011, though few, if any laptops have been made to run solar. I am researching ways to use microcontrollers to run a limited form of linux as well as drive a basic e-ink display like a solar calculator, rather than long recharging times as in the Samsung, which used an Atom cpu. In this video I was able to power a microcontroller on just indoor light: https://www.youtube.com/watch?v=0ztj_MDNRcI
I've tried to put together a laptop with a solar panel, but of course it is not yet practical: https://www.raspberrypi.org/forums/viewtopic.php?p=1784621#p...
Our discord group is here: https://discord.com/invite/nnxKnxh Feel free to check out our #solar & #paperterm projects!
> I was able to power a microcontroller on just indoor light
Wow!
Wow!
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.