E-inks are fundamentally analog, so theoretically you could have as many shades of gray as your timing resolution allows, but basically all the commercial controllers available abstract the display as a dumb framebuffer so you can't really access their fundamental operation of "make this pixel slightly whiter or darker.

That depends on what you exactly mean by "controller". The hardware controller typicaly has capability of exposing selected pixels to essentially arbitrary voltage level for specified amount of time and the framebuffer abstraction happens on the driver level.

The majority of dev kits and modules available abstract away that level and provide something not unlike a regular LCD where you just send it raster images; the driving waveforms etc. which are needed to do effects like this are abstracted away, and the details are kept secret.

Any examples? I've only played with Waveshare screens/drivers a little, but I'm pretty sure I saw the LUTs defining voltage levels and times on the "user side", e.g. within the examples code. And from a YT video that shown how to drive those screens at 3FPS (didn't try it myself yet), I assume those are the actual LUTs that convert abstractions into voltage control.

So many (all?) do this dumb thing on a page update where they write all black and all white several times then write the image. There can't be a good reason for that - they can also put up a dialog popup and erase it without all that drama! Its like they all took the demo driver and shipped it

The full black/white is to "cleanse" --- since the material itself is stateful, pixels will drift slightly after several writes and cause ghosting/graininess if you don't eventually reset them all to a known state. It doesn't have to happen on every refresh, however.

My partner and I both got a Kobo, we're very happy with it. We use Calibre to manage our collection. Haven't tried DeDRM yet though. I got the Kobo Aura ONE, and she's got the Kobo Aura H2O. I actually prefer the 6.8" yes it is smaller but it lays better in the hand and is easier to take with you (fits better in the pocket). Its also about 50 EUR cheaper.

Some disadvantages: macOS doesn't have always recognise the device, it has 2.4 GHz WiFi only (put if off to save your battery). The Kobo's also have that screen refresh feature btw you can reduce its effectiveness if you're reading a lot.

Immediately after you bought it, check out the coating of the screen very carefully. I send one ONE back because it had a minor damage to the coating which caused bleeding. I found that distracting, YMMV. The 2 devices got it as well, but less severe and it depends on how you hold the device whether you notice it.

As insinuated, I find it is overrated. You can even run Calibre in Docker [2] to serve it over HTTP(S). And as you know, Kobo have a web browser. So you could put the books you're likely to read on your Kobo (8 GB is a lot) and serve the rest via that way. You could also serve the content over your phone via USB OTG.

If you're off the grid for a long time, I actually recommend something else instead: put your smartphone off, e-reader on, and keep a (at your option relatively, to <3 your battery) charged powerbank with you. Not necessarily for your smartphone, but for your e-reader!

I know some publisher's don't use DRM (like Tor). I was wondering if maybe Kobo had licensed Amazon's DRM for the newer DRM that doesn't have a crack yet (as far as I know, but I haven't checked in a few months).

I got a reMarkable as part of the original lot of buyers. Haven't had quite as much time to use it as I'd like but can summarize:

-would like a little better contrast on the screen, though it does seem roughly on par with kindles and the like with lighting off

-epub generally works well

-full size (ie, letter) pdfs do require cropping unless your vision is superior. The on-device crop is fine for text only pdfs but recommend using an external cropper for pdfs that have charts. Going this route has made it possible to read Reviews of Moder Physics on the reMarkable without the need to squint.

-it could use a 20% speed bump. Some of this might be achieved in future software updates.

You can, of course, use it for its other intended purposes - note taking and draw/sketching.

Unfortunately my device has only "black & white", no shades of gray at all

That's because it's a module with its own controller for producing the display driving waveforms from the 1bpp data that you feed it --- but if you disassemble the module and figure out how to drive the display itself (it's probably not unlike the link above), you could get grayscale too. In addition, you could probably stream from network to display with almost no buffering, by clocking the data directly into the display as it's received over the network (although you'd have to clear each line before drawing it; unlikely to be very difficult, in any case.) Also, refresh as fast or slow as you want.

I've recently picked up a e ink display with a simple passive interface board (bc Im not used to working with flex cable yet) and realized that a popular way to build the frame in the mcu memory then dump it to the board. Most hobby mcus like the atemga328p have enough static memory to store whole frames of images and then push the whole image to the display, but don't have enough dynamic memory of you want to dynamicly render whole frames and then dump them. So I think that's what you are referring to when you said your trying to figure out how render the frames without running out of memory. My screen had example code that would draw frames an push small windows of image data to the screen to draw the different parts of a complete image.

The reason I bring this up is because I recently had the idea of using small SPI flash memory chips to render the whoel.inage frame dynamicly. The SPI memory chips look like a neat way to easily do this by hooking one up to a small mcu and drawing the frame using the spi memory chop then dumping the whole frame from the memory chip to the screen. I hope to oder some small DIPs soon to experiment with and I thought it also might interest you as well.

I'm not clear by what you mean; I'm new to the eink hardware scene and I don't know a lot about graphics rendering or how duble buffering works. It seems that from my understanding that you transfer the parts memory frame from the mcu to the memory on the eink display driver then you call the display driver to update the display and run the LUT tables and analog signals to do the stuff with the ink based on the current memory on the eink driver. However I am probably not right in some regards because not all eink displays have drivers and this process might not be case for all eink displays or I'm just misunderstanding how it works.

While I have not been following in detail anymore, I have not come across anything significant.

Note though that making it paper-like requires just a reflective display. Transreflective is needed only when it also needs to function as an emmissive display or needs a backlight.

Reflective displays suffer from poor colors as the pixels get divided into RGB areas, which is contrasting with a color print because the printer can put any color ink anywhere. This is the reason E-Ink, and every other reflective display has found it hard to develop good color.

I have longed for a responsive color, paper-like display for long also.

Mirasol was one promising technology for that (latest demos could get excellent colors as it also did not need to subdivide pixel area into different colors, as colors were created using interference). However, there is no activity on mirasol for the last several years.

I recently got a Waveshare 4.2" e-paper for my Pi, and I've been playing around with a variety of dithering algorithms to get it to display images.

The Floyd-Steinberg algorithm seems to bring out the most detail if you look at the image from a distance, but ordered dithering (with the 8x8 Bayer matrix from Wikipedia) gave me a better "retro computer" look that I was aiming for.

I believe the reason is that there are a lot of patents/IP around the core technology, and it's owned by very few companies who essentially have a monopoly on the market. This also explains the secrecy surrounding the "low-level" details. As this article shows, you can definitely get more gray levels by driving the display directly.

From past examples, we will likely not see any real innovation in this space until these patents expire. It's especially disheartening to me since I'll probably be too old to get in on the action by then.

I hope societies reevaluate the role of patents in the advancement of human technology. From my perspective, patents do more harm then good. They encourage rent-seeking. They're impractical to use legally unless you have enough money. They hold back technology for a couple of generations each time a new breakthrough is discovered (as has happened with capacitive touch screens, 3D printers, and is happening now with e-ink displays).