Looking for: Small, FOSS, long battery life

[ManDay]

Yeah thanks, I think the Kobo Mini doesn't match my requirement for screen resolution. Do you think the same will be possible on the Kobo HD?

Edit: I gather from one of the German threads that the solution should work equally well on a Touch and Glo, so that should include the HD!

[ManDay]

Originally Posted by dboddie

ManDay, I bought a Kobo Mini and was able to put my own kernel and user space distribution on it, so it's certainly possible. I wasn't interested in using the Wi-Fi module so I haven't looked at whether there's a truly free kernel module for that.?

Could you, in one or two sentences, please explain the graphics stack for the e-ink (i.e. kernel and userspace/x11 part)?

[kacir]

Originally Posted by ManDay

My concern is that I don't expect the default software configuration to provide what I need (i.e. a map, let alone with a good user interface) so I expect that I will hace to write my own program. By FOSS I just want to make sure I don't run into any unexpected problems due to closed-ness (e.g. I need a different kernel but I can't compile a working kernel because all the drivers are compiled in and propriatary).

The vast majority of e-ink reading devices out there run either on Linux or Android.
However, ALL of them are closed. Some more than others.

One of the most open traditional devices out there is PocketBook.
I currently own PocketBook Touch Lux 623.
It is relatively open device - you do not have to hack it to install third-party binaries, dictionaries, fonts, backgrounds, complete GUI revamp, alternative reading software, terminal emulator (with access to system, including Busybox userland binaries inside reader), FTP server that provides full access to system parititions, I have even installed full version of Vim on it.
There is even semi-official SDK available. I say semi-official, because Once Upon A Time (TM) they have released an SDK and haven't updated it for the newest firmware for a long time. But, it is obviously Good Enough (TM) to produce the aforementioned terminal emulator, Vim, third-party Coolreader, ftp server, a few games.

But! PocketBook developers have always jealously guarded the boot-loader and kernel (with proprietary drivers and libraries binaries) and other stuff, so that users and/or competitors couldn't get their software and install it on other Netronix based devices. Long time ago PocketBook used generic Netronix hardware that was also used by other OEM e-ink device "manufacurers" to produce similar devices with inferior software. Nowadays their hardware is custom-built by Foxcon I think.

To sum it up: I think that PocketBook is one of the most open [traditional Linux] devices out there, yet it is far from openness that you require.


Android devices are a minority among e-ink reading devices. Most of them, such as Sony PRS-T2 and T3 have been locked down real tight (no jailbreak or root at the time I last bothered to look). Some were easier to break into, such as Nook Simple Touch, the old Nook color, but they have a very old Android version (something like 2.2).
Recently a very interesting device has been introduced and started to sell here in Europe - Onyx Boox T68 with Android 4.something, full Google Play Store and other goodies. Have a look at recent posts in this thread: https://www.mobileread.com/forums/sho...d.php?t=225652

I am waiting for Onyx Boox Midia Inkphone E43 - a mobile phone with 4.3 inch e-ink diaplay, Android 2.3 (I know it *is* old, but at least you can install software to SD card, unlike on Nook Simple Touch), full Google Play Store. They have announced release for May 2014, then corrected the release date on their page for "May-June 2014", but I have a sinking feeling that they are not going to deliver in the next week or so ;-(
I am hoping they have postponed the release so they could provide better Android version or something.

[ManDay]

Thanks for the description kacir. I've never taken an ereader apart myself, but I think the "locking down" should be less of a problem than the lack of working drivers (which are open enough to integrate them with a user kernel).

I reckon that with a minimal set of electronic skills one can always open the device to gain direct access to its harddisk.

[kacir]

Originally Posted by ManDay

I've never taken an ereader apart myself, but I think the "locking down" should be less of a problem than the lack of working drivers (which are open enough to integrate them with a user kernel).

I reckon that with a minimal set of electronic skills one can always open the device to gain direct access to its harddisk.

I know that the PocketBook 360 Plus New does have an internal SD card, that can be taken out and read using card reader and a Linux computer. It has several weird partitions, plus device itself runs a few things in ramdisk where it decompresses/decrypts some things during runtime.
There are other devices (Kobo or Nook) that have internal SD card - I have read discussion just yesterday.

I have opened my PocketBook 623 and I can't see any SD card like PB360+ had. I can't see any obvious way to connect to the internal memory.

[dboddie]

Originally Posted by ManDay

Could you, in one or two sentences, please explain the graphics stack for the e-ink (i.e. kernel and userspace/x11 part)?

The standard stack writes directly to the framebuffer (no X11) using the Qt library. One running program is the display manager and the others are clients. The kernel is a modified version of 2.6.35.3 with support for the e-ink screen.

The stacks produced by members of this forum seem to be based on familiar desktop environments available for Linux distributions, such as Debian, and use X11 as a result.

I based my stack on Debian, too, but also use the Qt library to write directly to the framebuffer, so I'm running a kind of hybrid system. I use a kernel modified by Marek (who also produced a Debian-based image for the Kobo) that improves the level of support for the screen, and which works very well.

Does that make sense? I can provide links to various resources if you are interested.

[ManDay]

Originally Posted by dboddie

The standard stack writes directly to the framebuffer (no X11) using the Qt library. One running program is the display manager and the others are clients. The kernel is a modified version of 2.6.35.3 with support for the e-ink screen.

The stacks produced by members of this forum seem to be based on familiar desktop environments available for Linux distributions, such as Debian, and use X11 as a result.

I based my stack on Debian, too, but also use the Qt library to write directly to the framebuffer, so I'm running a kind of hybrid system. I use a kernel modified by Marek (who also produced a Debian-based image for the Kobo) that improves the level of support for the screen, and which works very well.

Does that make sense? I can provide links to various resources if you are interested.

Hm, sounds good. So these e-ink modifications to the kernel, they are a hand-written patch?

What do you mean by the Qt library writes directly to the FB? Is that some userspace driver thing or do you rather mean that the kernel has FB support for the eink (and Qt uses that FB?)

Any idea about how well written the eink part is (regarding energy efficiency, for example)?

The way you describe it, it looks like with the according e-ink patch I can have a working kernel with a working FB, which is just perfect (well, perfect would be if Marek could push his patch upsteam ).

Sure, any links and resources would be greatly appreciated!

[dboddie]

Originally Posted by ManDay

Hm, sounds good. So these e-ink modifications to the kernel, they are a hand-written patch?

I think they are additional files. It's a long time since I looked. The source for the modified kernel can be found in a Github repository.

What do you mean by the Qt library writes directly to the FB? Is that some userspace driver thing or do you rather mean that the kernel has FB support for the eink (and Qt uses that FB?)

As I understand it, the kernel provides a framebuffer device and Qt accesses that to change what is shown on screen. I've also written a simple Python module to do the same thing. The kernel code to handle the e-ink display manages things like updating it correctly. From userspace, libraries and applications are just using a standard framebuffer API.

Marek's version of the kernel can also be found on Github.

Any idea about how well written the eink part is (regarding energy efficiency, for example)?

I haven't looked very closely at it. I'll do some field testing soon.

The way you describe it, it looks like with the according e-ink patch I can have a working kernel with a working FB, which is just perfect (well, perfect would be if Marek could push his patch upsteam ).

Well, he recently replied to his own thread so maybe he's reading this.