I've been working on a linux distro for i.MX based e-paper readers (kindle, kobo, etc.) for a while and just had two other hackers join me on the project. Currently we are furthest along with the Kindle 4th generation non-touch with a slightly modified super minimal Debian booting and basic graphics support (Xorg works but no window manager and no screen auto-update yet. e-ink is weird). I believe we've managed to strip out all binary blobs so it's really all open source now. This system is still using an ancient kernel (a slight variation on the one used by the stock OS). We just got the latest stable kernel booting a few days ago but only barely (not even mmc support yet). There's just three of us for now, and we hang out in #fread.ink on freenode and our code is up on https://github.com/fread-ink

You should look at the repo https://github.com/fread-ink/fread-vagrant to get started.

https://www.mobileread.com/forums/showthread.php?t=275877

The Kindle hacking community believed they had a permanent solution prior to the release of the latest firmware version; unfortunately, Amazon seems to have finally found a way around it.

I'd recommend an older Kindle if you want to get root easier. 5th generation Paperwhite and older models should be cheap and have various exploits.

Probably would recommend a Kobo or something else though. Kindles are awesome pieces of hardware but they do try to keep them secure. Not the best choice for an open platform.

[1] https://wiki.mobileread.com/wiki/Kobo_Touch_Hacking

[2] https://wiki.mobileread.com/wiki/Debian_Linux_on_a_Kobo

Back in time they had some kind of third party development support, so you could plug addons into the existing UI. AFAIK the framework hasn't changed much to prevent that kind of dev, and there example addons built around it

But in terms of a random stable embedded environment that is quite transparent, with an awesome out of box hardware/software experience, Kobo are not to be beaten

Really? AFAIK, only parts of the distro are liberated, here:

https://github.com/kobolabs/Kobo-Reader

Most notably, the user interface itself ("Nickel") is completely missing from there: this makes it really hard to develop extensions for it. Some people have gone through great lengths to try and improve the firmware image, see for example this guy who went as far as writing his own QT plugin for the UI, basically bruteforcing his way through undocumented APIs and missing source code:

http://blog.ringerc.id.au/search/label/kobo

He gave up in 2011.

I did my own share of fooling around with the Kobo. It's true that it's very easy to hack: just drop a `KoboRoot.tgz` tarball in the `.kobo` directory, and you basically overwrite any part of the filesystem, which gives you a lot of freedom. I wrote a tool to sync my Kobo with Wallabag here called Wallabako:

https://gitlab.com/anarcat/wallabako/

But there's no APK, far from it: the Kobo suite is developped in typical proprietary fashion of keeping the secret sauce to themselves, not a collaborative way. And even though they are less hostile than Amazon in trying to keep people out, nothing says they will keep on being nice like this.

What we really need is a liberated hardware e-reader. There are some examples elsewhere in this thread that are interesting...

All in all it took me a few hours to write a simple application which renders the current time and date with a TTF font to the display.

There's a pretty decent dev community that has Qt fully working too which could offer you a good starting point. There are already full UI replacements going on in the community, like KoboStartMenu and KoReader.

The Kobo has no such protections, it's fully your own device and you can mod it as you see fit. Additionally, the whole OS is on an internal SD card and if you fuck everything up you can crack it open and reimage your SD card. Perfect tool for modders.

[1]: https://www.bq.com/es/cervantes-3-bq [2]: https://github.com/bq/cervantes

I'm planning on picking one up soon (or, hopefully, a Cervantes 4 if it comes out...). I'm (fortunately in a position where I can be) willing to pay the extra to support F/OSS out of the box :).

https://medium.com/@kylesf/my-experience-in-creating-the-wor...

Also, the C code you listed was very cute. :3

http://nooktalk.net/blog/reliable-way-to-root-nook-simple-to...

Simple Touch readers should be dirt-cheap.

You can configure it such that the Nook would boot and appear as normal, but holding down a key took you to the android launcher, and you would give up the use of two (redundant) buttons of your choice to control android-specific actions like <back>, etc.

This system was limited -- at the time -- to an older version of Android with limited app support, but if your purpose is to create your own apps this shouldn't pose any problem.

It's been advertised pretty heavily, and on the face of it looks like everything I want in an e-ink sketchbook/reader.

I have a suspicion that it will disappoint, however.

My own is quite old and the screen is not top-notch, I don't know how advanced and expensive they come right now. But give it a look.

But surely there must be breakout boards by now, right? Or a raspberry module that's larger than 3"? Can you effectively source raw screens through the usual hobby suppliers like digikey, mouser, jameco?

But yeah they are kind of complicated to drive. I've only used the small ones, but you do the refresh pattern manually - you also need to compensate for the temperature, and the pixel layout is a bit funky. Luckily there's already software for this at repaper.org, so you don't have to worry about it. The complicated logic being in software opens the doors for more complex refresh logic as well. Just keep in mind if you do this you can burn in the display, so buy a couple if you plan to experiment :)

What exactly is temperature compensation? I'm aware that it's a thing, but I haven't yet figured out what it is. Do you have to alter the drive voltage or current or something?

Also, I'm not currently aware of any open e-ink driver designs. A few people might be interested in the one you built, regardless of how simple it is. Of course standard disclaimers would apply.

The chip-on-glass has tons of registers to set drive voltages and the like, but the datasheet just gives you values to write to all of them.

What do you mean by e-ink driver? If you mean the software, check out the Arduino and Raspberry Pi librares on the repaper site. If you mean the hardware, just follow the schematics in the datasheet and repaper.org.

Oh! Nice.

> If you don't do it your display will just have less contrast in the code.

That's a really great failure mode for debugging/development :) you can just use a single repaint count until you have temperature sensing wired up.

> The chip-on-glass has tons of registers to set drive voltages and the like, but the datasheet just gives you values to write to all of them.

Oh okay - so there _is_ a controller. (I didn't know; totally ignorant about the subject.)

> What do you mean by e-ink driver?

Ah; I've just done some poking around, and I just realized I misunderstood things a bit when I last did some research (way too quickly, apparently) - I saw http://www.pervasivedisplays.com/images/Kits/Extension%20boa... and thought I'd need to cram everything on that board onto the final design. I didn't realize the displays were more or less self-contained (with a builtin/COG controller) and could be driven directly like LCDs or VFDs etc and that that board was the "kitchen sink" test/dev breakout kit.

Edit: Googling this seems to be a good resource [1] and it looks like it is using an msp430 so should be hackable. But I don't actually know much about this stuff, so if someone does hack it I'd love to know how

[1] http://forums.hackaday.com/viewtopic.php?f=2&t=846

More information on the technology:

http://kentdisplays.com/technology/ewriters

I'm curious why you think the jot 8.5 can save. I do know the earlier models were using an msp430, which others are suggesting cannot save the image. I actually have one of these Jots, but I don't know anything about hardware hacking so I'm not going to tear it apart (unless people just want pictures of the guts and possibly what chips are in there)

This would depend on whether the "read from LCD" capability is an intrinsic part of the ChLCD itself or a manufacture-time option, or if it's a separate capacitative or optical-barrier touch layer.

I just did a bit of digging, and I found some info on repairing the Boogie Board Rip on iFixit: https://www.ifixit.com/Guide/Boogie+Board+Rip+Internal+Anten... - this shows what looks like some kind of touch layer, along with a bunch of extra electronics.

There's also a smartphone showing a 1:1 copy of what's on the Jot on the fourth image as you scroll down at https://myboogieboard.com/ewriters/jot-8.5.

However the sync has a button which you can save the screen image and later upload it to your computer. What I'm wondering is on this device if you could do the reverse. I know being able to record the screen's state doesn't mean you can reproduce it. Just wondering if you can in this case.

I know nothing about ChLCD and that type of stuff. So this isn't really clear to me.

Regarding the Sync, I suspect it contains the same electronics as the Rip in order to do the sync thing, and a touch panel.

Based on the other comments I've read in this thread that explain how "writing" on screen (and "ink" showing up) is entirely mechanically driven, ie, the pressure on the surface of the display displaces the crystals and makes whatever you draw stay on the screen. Applying a voltage for a short moment somehow causes the crystals to reset.

I'm not sure why the display itself wasn't made writable. It's entirely possible Kent Displays simply couldn't find a viable way to market a (MCU-)writable version of this technology, and so they went in this direction instead; it's also possible that ChLCD (developed up to the point Kent have it at) doesn't have the capability to be addressed reliably. I have no idea.

I based my hunches above about how the Boogie Board resets on something I saw on TV a while ago, which I just determined is classified variously as "switchable privacy glass", "electrified privacy glass" or "intelligent glass". I learned (from the house-construction TV show) that it's essentially a single, gigantic (!) LCD "pixel", and I saw (in one of the construction stages) how simply plugging it into the wall and turning the wall switch on was what made it go from opaque to transparent. Obviously it's a fair jump from this to the Boogie Board reset mechanism, but it seems reasonable that some of the same ideas are used in both.

It's not a software controllable display. It uses a film concept similar to an etch-a-sketch and in the recording model, it uses a touchscreen to read the pen action, but there is no pixels/no matrix and no display that can be drawn to by software.

Essentially all I'm after is a Linux (not android) based 7-12" eink tablet with touch screen, a decent resolution / PPI for the size and at least say 2-4GB of ram at a minimum although if it was cheap enough I'd drop as far as 1GB if I really had to.

I have a Dasung E-Ink monitor and it's dreadful, lots of ghosting, very slow refresh, have to have some 'interesting' software running to make it work, hard to work with multi-desktops etc.... and very, VERY expensive: https://www.indiegogo.com/projects/paperlike-world-s-first-e... otherwise I'd attach that to a Pi or Cubox and live without the touch screen.

Thanks for the info about the Dasung. A video showing the screen at its absolute worst might be very useful - but to be fair, showing what things the screen does do well would be very interesting to know as well.

On the other hand, this means that the Chinese "photocopying industry" doesn't realize people want (decent!) e-ink readers. Window of opportunity, anybody?

http://essentialscrap.com/eink/ is probably one of the most helpful resources out there if you want to do this.