Easy debian install with prebuilt image.

[zacaj]

Just got this working, and its awesome. After chrooting a few times, I ran out of loop devices. It seems you need to pass -d to umount any loop mounted devices
ex:

umount -d /mnt/debian

You dont need it for sys,proc,etc though.
If you have this problem, you can do

losetup -d /dev/loop/1

for 1-7 to fix the unmounting, without needing to reboot or anything

On mounting the kindle partition (/mnt/us) in debian, I assume you can just do

mount -o bind /mnt/us /mnt/debian/mnt/us

Correct? Im not a real expert with mount, so there might be some problem with that, but its working fine for me so far. If it is correct, it might be good to add it to bootdebian.sh

[tolgame]

Hi,
I am about to order a kindle, just because this is awesome.
But I would like to know 2 things first:
1) is it possible to switch between Debian and KindleOS on the fly, or do you need to do USB networking? (I mean after the initial install)
2) Can Debian use the wifi? I read about accessing 3g here but not clear on if wifi works.
Thanks!

[zacaj]

1. yes, you can install luigi's terminal, and then change to debian with just a button combination, and switch back to kindleOS too, leaving each running in the background. It seems to be a bit finicky if you leave debian running something (like apt-get), with not letting you reenter debian while its still running, or something... I havent figured out exactly what though.
2. Yes, works with no changes

[tolgame]

Thanks! I just placed my order

[Xqtftqx]

Originally Posted by zacaj

Just got this working, and its awesome. After chrooting a few times, I ran out of loop devices. It seems you need to pass -d to umount any loop mounted devices
ex:

umount -d /mnt/debian

You dont need it for sys,proc,etc though.
If you have this problem, you can do

losetup -d /dev/loop/1

for 1-7 to fix the unmounting, without needing to reboot or anything

On mounting the kindle partition (/mnt/us) in debian, I assume you can just do

mount -o bind /mnt/us /mnt/debian/mnt/us

Correct? Im not a real expert with mount, so there might be some problem with that, but its working fine for me so far. If it is correct, it might be good to add it to bootdebian.sh

Thanks for the "-d" tip!

And yes, you can do that to mount the kindles storage. Im going to add a line next time i update the loader that will mount the kindle on /media so its easy to access

Originally Posted by zacaj

1. yes, you can install luigi's terminal, and then change to debian with just a button combination, and switch back to kindleOS too, leaving each running in the background. It seems to be a bit finicky if you leave debian running something (like apt-get), with not letting you reenter debian while its still running, or something... I havent figured out exactly what though.
2. Yes, works with no changes

To leave it running, (incase i pull the usb plug or something) you can
compile 'screen' and run it from the kindle (You can not apt-get screen, it wont work)

[zacaj]

I noticed that /dev only has null in it, is it normally like that, or did i do somthing wrong? if it is normally like that, is ther any way to get fb to show up?

[mark03]

Originally Posted by Xqtftqx

To leave it running, (incase i pull the usb plug or something) you can compile 'screen' and run it from the kindle (You can not apt-get screen, it wont work)

Sorry for the noob question, but what is special about "screen" that you can't apt-get it?

On a somewhat unrelated question: I read the comments about X not working because it requires VTs, and this feature isn't enabled in the Kindle kernel. Why can't we just recompile the kernel with VTs enabled? Someone (maybe you) alluded to it being harder to do that than to hack Xorg. Could you explain a bit why this is so?

If we forgo X, will graphical apps built on top of the Linux framebuffer (without X dependencies) still work out of the box? Someone should try netsurf, a web browser which you can build with a framebuffer (no X) backend.

OTOH, apparently the framebuffer doesn't "just work"---otherwise there wouldn't be talk of an fbterm "port" to Kindle. It would just run out of the box. I'd like to understand this more, if anyone cares to educate me

[hawhill]

Besides putting the right pixel data into the framebuffer - as in a memory area where pixel data is stored - the e-ink display must be triggered to refresh. It's not constantly refreshing as you would expect from other framebuffer based graphics output. As it's e-ink and a refresh is expensive in both power and time, you must have some logic that will refresh only when needed and maybe only what's needed.

The e-ink display has a controller that might
- do refreshes of rectangular areas in "fast" refresh mode (as done for cursors and the dictionary and menu pop-ups in the original software),
- and do refreshes of the full screen contents in "slow" mode (as done for page changes in the original software).

So you have to implement a refresh policy into software that just writes to the framebuffer and expects to be done.

As I have started experimenting with this myself (I have written - just another - Qt embedded video driver for the e-ink display), I can tell that there's software for which it's very hard to lay out a proper code path since you must often introduce differentiation between different graphical changes.

The most easiest approach is to introduce a simple "when it changes, refresh" policy. I think there was a "hack" floating somewhere in this forum that enables the X framebuffer server to do just this. In most cases, however, this is just to basic since in fact one perceived "display change" consists of a multitude of atomic changes.

Next iteration is to do "when it changes, wait a bit, and if there aren't any new changes, refresh". That's nice and all (and this is what I have done for Qt embedded), but it introduces new latency. You've got to get intimate with the application's program logic to really find the right moment to refresh. Just watching over framebuffer changes is expensive in both time or number-of-refreshes dimensions.

[mark03]

How was the guy who had xdaliclock running on his Kindle handling this, I wonder? I think there was ghosting. Does that come from not doing any explicit refreshes at all, or doing the "low cost" kind rapidly?

Somewhere I saw a reference to writing numbers to magic files in /sys to get different refresh operations. Is this the route a user app should take if it wants to decide when the screen gets updated, as opposed to delegating it to another layer like Qt?

Do you know how much of the e-ink fb driver in Kindle is mainline kernel and how much is custom?

[hawhill]

I think it was a simple shell script (or similar) that just wrote in regular intervals to the /proc pseudo-file (it's /proc, not /sys, I think) in order to refresh, so it was constantly refreshing. (Think: "while sleep 3; do echo 1 > /proc/.../refresh; done")
That's a simple trick to get any app to do output that at least does the memory part well. There's another thing I forgot to mention: The Kindle's memory layout for the framebuffer. It's 4bit, and this hits some applications very unprepared :-)

The /proc pseudo-files are one way to trigger refreshes, yes. I don't like them, however, since using this API means unnecessary string operations. But probably this overhead is negligible. The other way to do it is using private ioctls on the framebuffer device.

All of e-ink framebuffer is "custom" (but it builds upon the "mainline" framebuffer API). However, its code comes with the sources that Amazon provides. That way you can also get the C header file defining the ioctls for refreshing.

[mark03]

Originally Posted by hawhill

I think it was a simple shell script (or similar) that just wrote in regular intervals to the /proc pseudo-file (it's /proc, not /sys, I think) in order to refresh, so it was constantly refreshing. (Think: "while sleep 3; do echo 1 > /proc/.../refresh; done")

Interesting. I suppose that shortens the battery life

I spent a couple of hours skimming the kernel sources (e.g. broadsheet_hal.c), so I'm slowly learning. Any idea if there are C/C++ examples showing the use of those ioctls? I'm intrigued by the various refresh types, flashing vs nonflashing (?), etc. I wonder if the energy consumption scales linearly with the update area size, or if it also depends on the number of black-to-white or white-to-black pixel transitions within that area.

I'm thinking of writing a bike-computer app for my Kindle. I just need to get a reed switch wired to a keyboard key or side button. How hard could it be...

[hawhill]

Originally Posted by mark03

Any idea if there are C/C++ examples showing the use of those ioctls? I'm intrigued by the various refresh types, flashing vs nonflashing (?), etc. I wonder if the energy consumption scales linearly with the update area size, or if it also depends on the number of black-to-white or white-to-black pixel transitions within that area.

I've attached the code I've written as a gfxdriver for Qt embedded. Grep for the ioctls. But note that I'm only using a single one of them: the fast (but a bit dirty) refresh of rectangular areas. The driver in the kernel seems to be a bit more sophisticated but I didn't come across other code that uses it yet.

BTW, the code expects the kernel eink header file in the compiler's search path (see the include section in the gfxdriver).

I'm thinking of writing a bike-computer app for my Kindle. I just need to get a reed switch wired to a keyboard key or side button. How hard could it be...

Well, I'm more in the software side of things :-) But it should be feasible, I think. The buttons generate regular linux input events (which, BTW, is why no special keyboard driver is needed for Qt embedded, just a special keymap).

[jonj678]

I decided to alter the bootdebian script slightly, and was largely unsuccessful. The motivation for me is to run commands such as rsync (within debian) directly from the native OS. These would then be put in /etc/crontab.

chroot /mnt/debian /bin/bash -c "/root/sync.sh"

That much works fine, crontab and all. Provided that debian is mounted beforehand. This mount doesn't persist across reboots, so I added the following to fstab and unwisely typed reboot to verify that it mounted correctly. I was given a warning to the effect that I should have used "shutdown" instead, and the Kindle is now a brick. Which sucks. It gets partway through booting, and then stays on the start up screen forever. Either there's something terribly wrong in the following fstab entry, or "reboot" was a mistake, or there's a typo involved somewhere.

/mnt/us/debian.ext3   /mnt/debian         ext3    loop,noatime    0 0
/proc                         /mnt/debian/proc none   bind                 0 0
/sys                          /mnt/debian/sys  none   bind                 0 0
/dev                          /mnt/debian/dev   none   bind                 0 0

So, as a warning to anyone similarly minded, remember to use mount -a to verify fstab entries instead of rebooting, and it might be a bad idea to call reboot from the command line in any case.

Cheers

edit: Unrelated to the above, is apt-get working for other people in this thread? I couldn't get it to authenticate packages, either with the linked image or with one built from multistrap on a X86 system.

[mark03]

That's a bummer jonj

I imagine the next thing to do would be to build up a serial cable so you can watch the boot output and see where it is hanging up.

[mark03]

Originally Posted by hawhill

I've attached the code I've written as a gfxdriver for Qt embedded. Grep for the ioctls. But note that I'm only using a single one of them: the fast (but a bit dirty) refresh of rectangular areas. The driver in the kernel seems to be a bit more sophisticated but I didn't come across other code that uses it yet.

Thanks! I know next to nothing about Qt but it's most helpful to see a concrete example.

I've been looking through Jaya Kumar's old Linux/eink presentations and trying to figure out how "deferred I/O" plays into this. There is an interesting comment in the Amazon kernel sources, next to the deferred i/o stuff:

static void einkfb_deferred_io(struct fb_info *info, struct list_head *pagelist)
{
// At the moment, we're just using the deferred I/O mechanism to map in
// pages for us. We're not using it to update the display with since
// we have our own, more direct method for doing that.
}

static struct fb_deferred_io einkfb_defio =
{
.delay = HZ,
.deferred_io = einkfb_deferred_io,
};

It would be nice to know exactly how their "own, more direct method'" works in practice. Is it just user apps calling ioctls at the appropriate times, or do they have something else in the directfb layer?

BTW, I managed to find a presentation with some details of the various eink update types, on Baidu of all places:

http://wenku.baidu.com/view/187d5395...5f465e245.html

There is some good discussion of the tradeoff between non-flashing (fast but limited to black and white, and susceptible to ghosting) and flashing (slower but allows all grayscales and not susceptible to ghosting) updates. I think it is specific to the older (pre-Pearl) panel but probably still relevant.