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...
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.
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.
Funny coincidence, I'm developing okreader (https://github.com/lgeek/okreader), which is a package of u-boot, deblobbified downstream kernel images, Debian and KOReader (https://github.com/koreader/koreader) for a range of Kobo devices. I've been working with upstream KOReader developers to get the features required to use KOReader without the Kobo firmware. okreader replaces the whole software stack on the device.
I can also recommend the Pocketbook Touch Lux 3 for hacking. Changeable buildin microsd card, Allwinner A13 Soc and pins for serial connection. Only problem with it is touch and display controller. AFAIK they don't work with the mainline kernel.
Oh and what I didn't like about the Kobo reader software is their library and that they always want everything to index first. With the default Pocketbook firmware you can browse directory structures, so much superior if you have a very big library on it.
KOReader runs on many pocketbook models too ;) Although I am not 100% sure if it works for Lux 3 specifically since I don't have this model to test it myself.
Yeah, I should try KOReader on it at some point. Should work. Problem is just Pocketbook has own proprietary modules to load the touchscreen and display drivers, but that is just kernel space. I am not sure if that is even GPL compliant.
Does it still allow you to buy books from kobo.com ?
By the way, I was surprised how Amazon is making special offers to authors when they restrict the publication of their ebooks on Amazon's platform only, leading to some authors to stop publishing on Kobo. Found this out when my daughter could no longer buy the new books in a series she was reading. The author confirm the reason (and actually sent the new book epub for free).
Yes, it's an issue I've often seen. I really dislike this practice from Amazon. I can understand author's doing it since it's tough for self published authors to earn money but it's a monopolistic practice on the part of Amazon that doesn't sit well with me.
I didn't publish on Kobo's platform because their software arbitrarily decided that I wasn't allowed to, and none of my attempts to communicate with a customer service human to find out why generated any response.
I figured that I could still sell on Kobo via Smashwords, so didn't give it much thought.
In the end, my book is now exclusive to Amazon KDP for one, and only one, reason:
- royalties from Amazon = $24.60
- royalties from everyone else = $0
(It's not the amount. It's the principle.)
I was already de facto exclusive to Amazon, anyway.
I'm sure your readers appreciate being forced to purchase DRM-crippled copies of your book from a monopolist. Have you considered offering DRM-free EPUB downloads directly on your own site?
As should be apparent from the amount of the royalty, I don't have a significant quantity of readers. They all chose to buy the book via Amazon when it was also available on other [non-DRM] platforms.
I didn't force my readers to do anything. I followed their money to the only platform that paid off.
I have also elected to keep my day job. Offering free downloads wouldn't even be a waste of bandwidth, really--just a waste of server disk space. I don't have interests in both writing and marketing, so it doesn't make much difference to me if I am not making any money because no one knows who I am, rather than not making any money because nobody who knows who I am can figure out how to pay me anything.
Also, the only person who bought the book for whom I can be certain that they actually read it is my Mom, who left the most passive-aggressive 5-star review I have ever seen--simultaneously shilling for it and telling me how I should write the next book.
> Offering free downloads wouldn't even be a waste of bandwidth, really--just a waste of server disk space
You are very humble. :) I would be very surprised if there isn't someone who considered reading your work but didn't because it wasn't available online for free.
In fact, if your comment contained a direct link to a free copy of your work, someone from HN would already have looked.
Such a post would definitively link a pseudonym username to a real name. I'd have to create a throwaway.
It would also be offtopic anywhere but a Show HN thread, and even then seems iffy. The only bit of technical interest would be the script I wrote to finagle 7Zip into outputting a valid .EPUB file. 7Zip and plaintext editors were the only tools used. I'm not sure whether I am more afraid that no one would look, or that it would get an HN hug of death.
I did that and bought a Kobo to replace an old Kindle I had. But after a month I sold the Kobo and got a new Kindle.
The reason was that Kobo has a sliding power button that allows you to turn it on/off. This is different that putting it to sleep. In order to save battery, I often turned it off instead of leaving in sleep mode. This may be a minor difference, but Kindles don't give you that choice and I prefer Kindle's simplicity, which allows you not to care about how your decission between off/sleep would affect the charge. People talk about this topic in forums https://www.mobileread.com/forums/showthread.php?t=146967
There is an additional side effect of the missing directory browser: every sync cycle results in it rebuilding its (apparently sql-lite) DB. This is particularly a problem if you happen to have a large number of books - one ends up waiting 15 minutes or more for this process to complete. As soon as I could, I moved my Kobo Aura HD to KOReader+FileManager.
At least in my experience, most of the e-reader hacking going on is over at the mobileread.com forums, in the "Developers Corner" subforums. Both the Kindle and the Kobo Dev Corners are pretty active, with lots of information.
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...