Comment by acabal | Hacker News Reader

Comment by acabal | Hacker News Reader

Very interesting and timely considering I just bought a Kobo Aura One. The Aura One is a really nice device, and you don't realize how small and uncomfortable the Kindle Voyage is until you use a big device with a textured back. Plus the eink Kobo's epub rendering engine is easily best-in-class. It blow's Kindle's rendering capabilities out of the water. (Assuming you use their dumb ".kepub.epub" format extension--if you upload regular epubs it'll fall back to rendering with Digital Editions, Adobe's eldritch horror of a renderer.)

If OcherBook is meant to entirely replace the Kobo firmware, why not base the document rendering portion on something like Readium? That's another best-in-class renderer designed to be used in other software but it seems like it's almost always overlooked.

On a side note, It's always been a faraway dream of mine to do a Kickstarter-like project to fund a completely open and libre eink ebook reader. As far as hardware startups go it'd be on the simpler side (the stripped-down minimum device is just a touch eink screen, ram/cpu/storage, usb-c; wifi and backlight not required). But, I have zero hardware experience and honestly I don't know if it'd be a venture that could be made profitable or not. Kindle/Kobo devices are loss leaders for their ebook store, so an ereader without a store, and competing on just libre-ness can't compete on price. If anyone's interested in chasing the dream, get in touch...

One of the KOReader maintainers here ;)

I have been discussing with other maintainers (mostly @chrox) about starting a full stack open and libre eink reader for more than a year. Now that @lgeek has done the ground work at the firmware and OS level, coming up with the hardware design is the last piece. I am happy you are interested in this too. I will definitely reach out to you through emails. Meanwhile, if anyone else is also interested in this, please feel free to join our gitter channel at https://gitter.im/koreader/koreader for further discussion. I will be hanging out there after work hour (PST).

And yes, we are also evaluating readium. Right now, we are using coolreader's awesome engine for epubs.

Great work with KOReader!

I tried KOReader on my Kobo Glo some time ago. But I think there was a problem that it always froze after some time. Never had the time and opportunity to further analyze it to give a good bug report. I really should try the latest version of it on all my ebook readers. So much to do and so little time ;)

FYI, the OEM (ODM?) for Kobo devices is Netronix (http://www.netronixinc.com/index.aspx). On their platforms, the most challenging bits to liberate will be the EPDC firmware (which is specific to each panel model) and E Ink's Regal library (although the latter isn't required - I've dropped it in okreader). I expect that even if you'd get your own devices manufactured, those would still be problematic. You'd probably also want to go for a non-Broadcom WiFi adapter vendor, to avoid runtime firmware loading.

> the most challenging bits to liberate will be the EPDC firmware

Could you clarify exactly what you mean by "EPDC firmware"?

afaik, it is already published so what needs to be "liberated"?

The devices you're talking about, eg: on your github, are the i.mx series of SoCs have an on-chip EPDC which is open source (the datasheets show all the registers) and the driver is also GPL. Eg: https://github.com/UDOOboard/Kernel_Unico/blob/master/driver...

In case you mean the .fw file used in that driver, that's a misnomer. There is no CPU inside the EPDC. That .fw file is a plain voltage waveform file that defines voltage vs time waveforms to get pixels to appropriate graylevels. "Liberating" that would be akin to "liberating" the content of a .wav file. ie: just use hexdump -C.

> In case you mean the .fw file used in that driver, that's a misnomer. There is no CPU inside the EPDC. That .fw file is a plain voltage waveform file that defines voltage vs time waveforms to get pixels to appropriate graylevels. "Liberating" that would be akin to "liberating" the content of a .wav file. ie: just use hexdump -C.

I meant the waveform data at offset 0x700000 on the internal storage of the Kobo devices (which is similar but not the same as the .fw files in firmware/imx/). It's not clear whether distribution is allowed.

> I meant the waveform data at offset 0x700000 on the internal storage of the Kobo devices

Waveform data is unique to each batch of panels and there are also tuning parameters for each batch of power management circuitry in a board. A Kobo with a 2015 panel will have different waveform data than a 2016 panel. More expensive panels contain the waveform in a flash on the panel which can be read by the host. Cheaper vendors will try to cut cost and just store the waveform in main flash. But that has caused some problem because end user accidentally flashes wrong firmware with a waveform that doesn't match the panel and bam, the panel quality is degraded, maybe even permanently.

It's actually using RMSDK and not Digital Editions.

Reply on news.ycombinator.com