06-05-2011, 06:31 PM | #16 |
Junior Member
Posts: 6
Karma: 10
Join Date: Mar 2011
Location: NY
Device: Kindle 3 3G
|
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: Code:
umount -d /mnt/debian If you have this problem, you can do Code:
losetup -d /dev/loop/1 On mounting the kindle partition (/mnt/us) in debian, I assume you can just do Code:
mount -o bind /mnt/us /mnt/debian/mnt/us |
06-06-2011, 03:08 PM | #17 |
Junior Member
Posts: 6
Karma: 10
Join Date: Mar 2011
Device: kindle 3
|
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! |
06-06-2011, 03:48 PM | #18 |
Junior Member
Posts: 6
Karma: 10
Join Date: Mar 2011
Location: NY
Device: Kindle 3 3G
|
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 |
06-06-2011, 04:27 PM | #19 |
Junior Member
Posts: 6
Karma: 10
Join Date: Mar 2011
Device: kindle 3
|
Thanks! I just placed my order
|
06-07-2011, 03:52 PM | #20 | ||
Enthusiast
Posts: 31
Karma: 246
Join Date: Mar 2011
Device: Kindle 3G
|
Quote:
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 Quote:
compile 'screen' and run it from the kindle (You can not apt-get screen, it wont work) |
||
06-08-2011, 02:49 PM | #21 |
Junior Member
Posts: 6
Karma: 10
Join Date: Mar 2011
Location: NY
Device: Kindle 3 3G
|
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?
|
06-08-2011, 04:11 PM | #22 | |
Enthusiast
Posts: 30
Karma: 10
Join Date: Jun 2011
Device: Kindle 3 wifi
|
Quote:
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 |
|
06-08-2011, 06:45 PM | #23 |
Wizard
Posts: 1,379
Karma: 2155307
Join Date: Nov 2010
Location: Goettingen, Germany
Device: Kindle Paperwhite, Kobo Mini
|
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. |
06-08-2011, 10:50 PM | #24 |
Enthusiast
Posts: 30
Karma: 10
Join Date: Jun 2011
Device: Kindle 3 wifi
|
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? |
06-09-2011, 04:48 AM | #25 |
Wizard
Posts: 1,379
Karma: 2155307
Join Date: Nov 2010
Location: Goettingen, Germany
Device: Kindle Paperwhite, Kobo Mini
|
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. |
06-09-2011, 02:30 PM | #26 | |
Enthusiast
Posts: 30
Karma: 10
Join Date: Jun 2011
Device: Kindle 3 wifi
|
Quote:
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... |
|
06-09-2011, 03:14 PM | #27 | ||
Wizard
Posts: 1,379
Karma: 2155307
Join Date: Nov 2010
Location: Goettingen, Germany
Device: Kindle Paperwhite, Kobo Mini
|
Quote:
BTW, the code expects the kernel eink header file in the compiler's search path (see the include section in the gfxdriver). Quote:
|
||
06-10-2011, 12:40 PM | #28 |
Member
Posts: 11
Karma: 10
Join Date: May 2011
Device: Kindle 3
|
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.
Code:
chroot /mnt/debian /bin/bash -c "/root/sync.sh" Code:
/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 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. Last edited by jonj678; 06-10-2011 at 12:44 PM. |
06-10-2011, 01:44 PM | #29 |
Enthusiast
Posts: 30
Karma: 10
Join Date: Jun 2011
Device: Kindle 3 wifi
|
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. |
06-10-2011, 01:57 PM | #30 | |
Enthusiast
Posts: 30
Karma: 10
Join Date: Jun 2011
Device: Kindle 3 wifi
|
Quote:
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. |
|
Thread Tools | Search this Thread |
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Install in Bubba server (Debian Linux bubba 2.6.32.6) | cc_humbry | Calibre | 5 | 07-24-2010 11:22 AM |
Can't install under Debian Lenny | cbalmforth | Calibre | 2 | 07-01-2010 12:59 PM |
Install Calibre in Debian Lenny? | erdalronahi | Calibre | 8 | 05-16-2010 12:49 AM |
Debian on the Kindle | freezer2k | Kindle Developer's Corner | 20 | 02-08-2010 08:52 PM |
Debian 3.1 Released | Chaos | Lounge | 3 | 06-08-2005 09:01 AM |