4 ms·

Using a typical desktop operating system, but on an eInk screen, is one of those things that sounds cool, but I suspect the reality after using it for a while w

Using a typical desktop operating system, but on an eInk screen, is one of those things that sounds cool, but I suspect the reality after using it for a while will be "Never mind, this sucks, because no software (including the OS itself) was designed with working well on sluggish & image-persistence-afflicted panels in mind". I think doing this concept properly is as much of a software project as a hardware project.

solarkraft 4y ago
I use normal Android apps on my R-Reader. With some contrast settings and animations (mostly) turned off it's quite nice. However the animations that are still around (loading spinner, animated GIF) can be quite annoying. A mouse pointer may itself be a bit hard to display on an E-Ink Screen. It will definitely leave a trail behind.
GekkePrutser 4y ago
If you work mainly in terminals it will be OK I think. Something like i3 and off you go.
PMunch 4y ago
I have some insight in this as I'm currently building a very similar project myself. I'm using off-the-shelf components and the relatively cheap USB driver board for the 10.3" ePaper display is more than capable enough of showing a variety of content. Typing in a document or code is plenty fast, scrolling a webpage is usable, but you'd probably want to use PgUp/PgDown, moving the mouse around is fine but I'm using a tiling window manager to avoid having to drag windows around. I'm able to drive video, but it's quite choppy. In general small updates are plenty fast (like showing characters next to a cursor) and big updates are slow (like full screen video playback). Playing video in a small window is fine if you just want to get some information out of it. All these speeds are in a dithered 1-bit mode though. As soon as you start playing around with grayscale things starts going slow (you essentially need to display N levels of grayscale as N frames). The system I'm using is capable of updating parts of the display in 1-bit mode and others in "high-fidelity" 16 levels mode. This means that I could e.g. tell it that my picture viewing program should use the full quality mode, and my text editor should use the fast mode. Since I'm using a tiling window manager opening a picture would then use about a second to display the image, but once it's there I could type into a window next to it at full speed. It could also allow me to highlight areas to redraw in high-quality mode if I was browsing a website for example and wanted to watch a particular image.
- bee_rider 4y ago
  Greyscale might be nice for syntax highlighting. I wonder, is there any practical way to do 1-bit just around the cursor?
  - PMunch 4y ago
    I have looked a little bit into it. The problem is that grey scale requires flashing the area on and off a lot, so it's quite visibly disturbing. My idea was to first draw the character in fast mode, then if it hadn't been touched for a while update it in grey scale mode. I haven't tried implementing this yet, but it might work if the blinking isn't too disruptive. Having syntax highlighting would definitely be nice, other ways of getting it I've though about is getting my editor to use fonts for highlighting instead of color.
dredmorbius 4y ago
Unix was originally designed to work on teletypes, which are even slower and higher-latency than e-ink. Having used an e-ink device heavily for over a year, including both local (Termux) and remote (SSH) system use via it and a keyboard, I'm conveninced that for text-heavy work it's fully functional, and would probably be viable with a sufficiently-thoughtful GUI which adhered to the design principles and respected the imitations of e-ink: 1. Persistence is free. 2. Pixels are cheap 3. Paints are expensive 4. Refreshes are slow 5. Colour is limited to nonexistent. 6. Pagination over scroll. 7. Full refresh (of page or portion) over pan. 8. Reflective rather than emissive. 9. Minimise animation. 10. Line-art or halftones over shade gradients (images).
- outworlder 4y ago
  That's essentially older GUI desktops before GPUs did more than just provide an interface for the monitor. Paints used to be very expensive (and remained so for quite a while). Pixel scrolling also took a while to appear on consumer desktops.
  - dredmorbius 4y ago
    For older computers, the limitation was in the graphics card itself. Monitors could respond limited only by scan and refresh rates, typically 60--120 Hz, possibly better. For e-ink, it's the electrophoretic display itself which imposes lag. It's a bit like pushing a wet noodle or a heavy arm. No matter how fast the graphics card is responding, the physical display simply can't keep up and iposes inertia on changes. Again, for text-heavy applications and reasonably static imagery, this isn't much of a problem. Current displays can cycle between refresh modes, and it's possible to trade image quality for response time. Presently that's only possible for the whole display at a time, but I might imagine it would be possible to zone a display such that a portion is at a high-fidelity mode and another at a lower-fidelity, higher-refresh mode. If the idea is for a low-distraction device, I'm not sure that's actually the direction you'd want to go in, however.
    - outworlder 4y ago
kitsunesoba 4y ago
Well, that's certainly true for the majority of modern software, but the operating systems of yore and the software that ran on them was designed to handle old slow LCDs and restricted color environments quite well. Mac OS up through System 7.5.5 works excellently on such displays, because it had to run on several models of PowerBook with black and white or grayscale passive matrix displays, which were notoriously slow. While not as good, black and white support remains decent all the way through the end of Classic Mac OS, with version 9.2.1. For this reason, when imagining an e-ink semi-unitasker laptop such as this I imagine it being built with extremely low power hardware and running old operating systems, such as the aforementioned Classic Mac OS. I'm sure DOS/Win3.1/WinNT could stand in here too, probably more easily since 486/586/Pentium-compatible x86 CPUs are still being manufactured. One wouldn't be able to run Google Docs on such a machine, but there's a veritable cornucopia of abandonware readily available for such platforms at places like Macintosh Garden[0], and given highly specific use case of such a machine I think most people could find something that suits their needs. [0]: https://macintoshgarden.org https://macintoshgarden.org
- hoistbypetard 4y ago
  I used and repaired those in the 1990s. System 7 was usable on those, to be sure, but I don't remember anything about it as "excellent". Everyone thought they kind of sucked. You could see the ghosting even then, and by the end of 1992 or 1993, IIRC, Apple stopped shipping passive matrix displays. e-ink displays are not even up to that standard of responsiveness yet. And, as you point out, modern software has higher expectations than the systems that kind of sucked on those old passive matrix LCDs.
dbtc 4y ago
The terminal was made for e-ink displays ;)
- WesolyKubeczek 4y ago
  Except when scrolling, gods forbid you scroll on an eink screen.
Vekz 4y ago
All you need is Emacs and you got a whole operating system designed for reading and editing text in a limited environment.

solarkraft 4y ago

I use normal Android apps on my R-Reader. With some contrast settings and animations (mostly) turned off it's quite nice. However the animations that are still around (loading spinner, animated GIF) can be quite annoying. A mouse pointer may itself be a bit hard to display on an E-Ink Screen. It will definitely leave a trail behind.

GekkePrutser 4y ago

If you work mainly in terminals it will be OK I think. Something like i3 and off you go.

PMunch 4y ago

I have some insight in this as I'm currently building a very similar project myself. I'm using off-the-shelf components and the relatively cheap USB driver board for the 10.3" ePaper display is more than capable enough of showing a variety of content. Typing in a document or code is plenty fast, scrolling a webpage is usable, but you'd probably want to use PgUp/PgDown, moving the mouse around is fine but I'm using a tiling window manager to avoid having to drag windows around. I'm able to drive video, but it's quite choppy. In general small updates are plenty fast (like showing characters next to a cursor) and big updates are slow (like full screen video playback). Playing video in a small window is fine if you just want to get some information out of it. All these speeds are in a dithered 1-bit mode though. As soon as you start playing around with grayscale things starts going slow (you essentially need to display N levels of grayscale as N frames). The system I'm using is capable of updating parts of the display in 1-bit mode and others in "high-fidelity" 16 levels mode. This means that I could e.g. tell it that my picture viewing program should use the full quality mode, and my text editor should use the fast mode. Since I'm using a tiling window manager opening a picture would then use about a second to display the image, but once it's there I could type into a window next to it at full speed. It could also allow me to highlight areas to redraw in high-quality mode if I was browsing a website for example and wanted to watch a particular image.

bee_rider 4y ago
Greyscale might be nice for syntax highlighting. I wonder, is there any practical way to do 1-bit just around the cursor?
- PMunch 4y ago
  I have looked a little bit into it. The problem is that grey scale requires flashing the area on and off a lot, so it's quite visibly disturbing. My idea was to first draw the character in fast mode, then if it hadn't been touched for a while update it in grey scale mode. I haven't tried implementing this yet, but it might work if the blinking isn't too disruptive. Having syntax highlighting would definitely be nice, other ways of getting it I've though about is getting my editor to use fonts for highlighting instead of color.

dredmorbius 4y ago

Unix was originally designed to work on teletypes, which are even slower and higher-latency than e-ink. Having used an e-ink device heavily for over a year, including both local (Termux) and remote (SSH) system use via it and a keyboard, I'm conveninced that for text-heavy work it's fully functional, and would probably be viable with a sufficiently-thoughtful GUI which adhered to the design principles and respected the imitations of e-ink: 1. Persistence is free. 2. Pixels are cheap 3. Paints are expensive 4. Refreshes are slow 5. Colour is limited to nonexistent. 6. Pagination over scroll. 7. Full refresh (of page or portion) over pan. 8. Reflective rather than emissive. 9. Minimise animation. 10. Line-art or halftones over shade gradients (images).

outworlder 4y ago
That's essentially older GUI desktops before GPUs did more than just provide an interface for the monitor. Paints used to be very expensive (and remained so for quite a while). Pixel scrolling also took a while to appear on consumer desktops.
- dredmorbius 4y ago
  For older computers, the limitation was in the graphics card itself. Monitors could respond limited only by scan and refresh rates, typically 60--120 Hz, possibly better. For e-ink, it's the electrophoretic display itself which imposes lag. It's a bit like pushing a wet noodle or a heavy arm. No matter how fast the graphics card is responding, the physical display simply can't keep up and iposes inertia on changes. Again, for text-heavy applications and reasonably static imagery, this isn't much of a problem. Current displays can cycle between refresh modes, and it's possible to trade image quality for response time. Presently that's only possible for the whole display at a time, but I might imagine it would be possible to zone a display such that a portion is at a high-fidelity mode and another at a lower-fidelity, higher-refresh mode. If the idea is for a low-distraction device, I'm not sure that's actually the direction you'd want to go in, however.
  - outworlder 4y ago

kitsunesoba 4y ago

Well, that's certainly true for the majority of modern software, but the operating systems of yore and the software that ran on them was designed to handle old slow LCDs and restricted color environments quite well. Mac OS up through System 7.5.5 works excellently on such displays, because it had to run on several models of PowerBook with black and white or grayscale passive matrix displays, which were notoriously slow. While not as good, black and white support remains decent all the way through the end of Classic Mac OS, with version 9.2.1. For this reason, when imagining an e-ink semi-unitasker laptop such as this I imagine it being built with extremely low power hardware and running old operating systems, such as the aforementioned Classic Mac OS. I'm sure DOS/Win3.1/WinNT could stand in here too, probably more easily since 486/586/Pentium-compatible x86 CPUs are still being manufactured. One wouldn't be able to run Google Docs on such a machine, but there's a veritable cornucopia of abandonware readily available for such platforms at places like Macintosh Garden[0], and given highly specific use case of such a machine I think most people could find something that suits their needs. [0]: https://macintoshgarden.org https://macintoshgarden.org

hoistbypetard 4y ago
I used and repaired those in the 1990s. System 7 was usable on those, to be sure, but I don't remember anything about it as "excellent". Everyone thought they kind of sucked. You could see the ghosting even then, and by the end of 1992 or 1993, IIRC, Apple stopped shipping passive matrix displays. e-ink displays are not even up to that standard of responsiveness yet. And, as you point out, modern software has higher expectations than the systems that kind of sucked on those old passive matrix LCDs.

dbtc 4y ago

The terminal was made for e-ink displays ;)

WesolyKubeczek 4y ago
Except when scrolling, gods forbid you scroll on an eink screen.

Vekz 4y ago

All you need is Emacs and you got a whole operating system designed for reading and editing text in a limited environment.