01-26-2013, 11:54 AM | #31 | |
Addict
Posts: 348
Karma: 209937
Join Date: Jan 2012
Location: Virginia, US
Device: Kobo Wifi, Kobo Glo
|
That's quite cool, ah-! I've been thinking about trying to get debian running on my Glo as well.
Quote:
|
|
01-26-2013, 12:32 PM | #32 |
Connoisseur
Posts: 64
Karma: 7786
Join Date: Jan 2012
Device: Kobo Touch
|
These binaries are fantastic, that's much faster. At some point it would be nice if it worked without them but for now it's fine.
I uploaded my debian image to http://andreas.heider.io/kobo_debian/debian.ext3, together with http://andreas.heider.io/kobo_debian/debian.sh you should get a working debian squeeze chroot. I used xserver-xorg-video-imx and a few libraries from the Kindle images to get the screen working. Since all the code is open source you might also be able to compile it, but I don't have a cross compilation environment set up at the moment. To get X with fluxbox and xterm running, copy everything to /mnt/onboard, login via telnet/ssh and start /mnt/onboard/debian.sh to get a chroot shell. Oh, and kill nickel first, of course. Start "Xorg -verbose 9" in one shell, then connect again and start "DISPLAY=:0 fluxbox" and maybe "DISPLAY=:0 xterm". Then connect to another shell but don't chroot to debian, cd to /mnt/onboard/debian/fb_update and run ./eink_update_loop.sh There's nothing really specific to the Touch, so maybe it just works on the Glo. It's missing some way to click or input text, so maybe we can get tap to click working or repurpose the buttons as mouse buttons. Edit: I just noticed, I mixed up squeeze and testing, it's testing with squeeze in /etc/apt/sources.list, if you want to tinker it's probably a good idea to replace it there with testing and do a apt-get dist-upgrade. I'll probably upload a fixed image later. Edit2: Don't do the apt-get dist-upgrade, the kindle imx_drv.so isn't compatible with the newer Xorg in testing. Last edited by ah-; 01-26-2013 at 02:20 PM. |
Advert | |
|
01-26-2013, 02:48 PM | #33 |
Addict
Posts: 348
Karma: 209937
Join Date: Jan 2012
Location: Virginia, US
Device: Kobo Wifi, Kobo Glo
|
Awesome, it works! It doesn't fill the whole screen on my Glo, but that can be fixed. Thanks for the little how-to, ah-!
|
01-27-2013, 04:34 AM | #34 |
Time Waster
Posts: 422
Karma: 289160
Join Date: May 2011
Device: Kobo Glo and Aura HD
|
Hi, sorry for the long absence
I've made some research. Since it became clear the thing was not so straightforward as I hoped, I went on to work on KPV as training What I've found out so far: - The Kobos use kernel code that manages the eink panel that is almost identical to the one used by amazon until firmware 5.0.x. Since 5.1.x amazon modified a struct in the ioctl that is used to update the panel, and compatibility is lost. We need either to intercept those calls and translate them to the amazon equivalent, or create a custom kernel that won't be compatible with kobo software. - The kindles use for touch events a multitouch protocol, while kobos just send x,y coordinates and pressure. This is a shame since the hardware is well capable to track more than one finger at once. This probably is less of a problem since in kernel documentation it states "Since Multitouch events are ignored by applications that require single touch, this protocol can be implemented on top of existing drivers", more or less. So again custom kernel but we retain compatibility with current software. I don't really know other approaches on replacing kernel code; I know that if it were a module it would be sufficient to unload it and load our custom one, but the code we need is internal to the kernel. Finding out how to overcome those two aspects will be useful even for other things: as an example, in the same way we could modify the driver for the frontlight and drive it lower than the minimum. Please anyone share your knowledge if you have information on the issue! |
01-28-2013, 04:38 AM | #35 |
Wizard
Posts: 1,379
Karma: 2155307
Join Date: Nov 2010
Location: Goettingen, Germany
Device: Kindle Paperwhite, Kobo Mini
|
It should be much more easy to implement the Kobo APIs in KPV. After all, it's just a bit of C glue code. No need to touch the kernel, I think.
|
Advert | |
|
01-28-2013, 05:45 AM | #36 | |
Time Waster
Posts: 422
Karma: 289160
Join Date: May 2011
Device: Kobo Glo and Aura HD
|
Quote:
I was speaking about making the proprietary Kindle software to run on Kobo. |
|
01-28-2013, 10:08 AM | #37 |
Wizard
Posts: 1,379
Karma: 2155307
Join Date: Nov 2010
Location: Goettingen, Germany
Device: Kindle Paperwhite, Kobo Mini
|
Ah, I misunderstood you there. Well, nice project! That's what I love about Open Source software... Unexpected outcomes and profit for everyone.
|
01-28-2013, 01:11 PM | #38 | |
but forgot what it's like
Posts: 741
Karma: 2345678
Join Date: Dec 2011
Location: north (by northwest)
Device: Kindle Touch
|
Quote:
EDIT: OK, I see you already did it. Nice. Last edited by eureka; 01-28-2013 at 01:16 PM. |
|
01-28-2013, 06:42 PM | #39 | |
Connoisseur
Posts: 64
Karma: 7786
Join Date: Jan 2012
Device: Kobo Touch
|
Regarding the original goal of this thread, I'm having problems with getting devcap-daemon to run. That's the only error message left when I try to start framework.
I faked /proc/board_id and /dev/mmcblk0p3 with 00A (any idea which board_id/codename is closest to the Kobo touch?) and a few zeros respectively, but it now dies with: Quote:
|
|
01-29-2013, 03:55 AM | #40 | |
Time Waster
Posts: 422
Karma: 289160
Join Date: May 2011
Device: Kobo Glo and Aura HD
|
Quote:
I've added some scripts and the kernel module I use to fake board_id. I use a code that I found online, I don't think it is an issue to share it here but if we come up with something working it will have to be modified with something non-existing. A step I think is necessary to make the software run is to configure the framebuffer to 8bpp, that's what framebuffer_configure does, it is used also in my port of KPV. BTW, where did you get that log? I'm just using strace at the moment since I can't get a proper log. Never had references to devcap but maybe I just didn't notice. |
|
01-29-2013, 04:55 AM | #41 | |
Connoisseur
Posts: 64
Karma: 7786
Join Date: Jan 2012
Device: Kobo Touch
|
Quote:
I think that possibly the framebuffer configuration is no problem, since X already runs and could do that for us. Also, instead of using a kernel module I just modified the paths in the binary as a quick hack, but I'd be interested in the kernel module as well. Or maybe a LD_PRELOAD library that redirects these specific paths would be a good idea, since that would mean that it works without having to build a kernel module or modifying the binaries. |
|
01-29-2013, 08:20 AM | #42 |
but forgot what it's like
Posts: 741
Karma: 2345678
Join Date: Dec 2011
Location: north (by northwest)
Device: Kindle Touch
|
If it's like Kindle Touch Wi-Fi then it will be whitney with board_id starting from 006. In some places it's also called whitney_wfo to distinct it from full whitney, i.e. Kindle Touch 3G. Also take a look at /etc/upstart/functions and at this thread.
Last edited by eureka; 01-29-2013 at 08:22 AM. |
01-29-2013, 03:21 PM | #43 |
Time Waster
Posts: 422
Karma: 289160
Join Date: May 2011
Device: Kobo Glo and Aura HD
|
You're right, devcap doesn't work here as well. I've currently modified the line referring to it in the framework in order to pass this. I still can't figure out what is the "config file" you're speaking about.
|
01-29-2013, 05:39 PM | #44 | |||
Connoisseur
Posts: 64
Karma: 7786
Join Date: Jan 2012
Device: Kobo Touch
|
Quote:
Quote:
Quote:
Edit: And some process: The error I got was due to a old shm region still being around, removing it with ipcrm -M 0x00008fb5 helped. Now to solve some ioctl error. Last edited by ah-; 01-30-2013 at 12:17 AM. |
|||
01-30-2013, 11:51 AM | #45 |
Connoisseur
Posts: 64
Karma: 7786
Join Date: Jan 2012
Device: Kobo Touch
|
Ok, with devcap-daemon working the framework seems to start.
The screen stays black, and strace says it waits for a futex, so I guess it requires some other service to start up properly. But I'll investigate that later. Edit: After a bit more poking around and especially executing /etc/upstart/firstboot and prereg.conf manually as well as unpacking more cramfs.img from /etc/loopbacktab and setting the framebuffer to 8bit thanks to your framebuffer_configure it now really starts , still with tons of errors but I get a white window and touching the screen results in messages in the log. I see exceptions about missing images, but I haven't found out yet which images are missing and why. Starting the onscreen keyboard (/usr/bin/kb) leads to the same error and is a lot less complex, so probably investigating that is easier. Edit 2: So it seems that this is just what you hinted at in the first posts, the screen update is different. I'm still looking at it, but I suspect awesome (the window manager) to be somehow responsible for it. Starting it pretty much corrupts the display, but upon a closer look the onboard keyboard letters are there in between the corruption. Edit 3: And it somewhat works :) Last edited by ah-; 01-30-2013 at 04:57 PM. |
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
F-Zero 4K, code ported, now it needs dumbing down. WIP... | twobob | Kindle Developer's Corner | 2 | 09-06-2012 10:12 AM |
Android [WIP] Overclocking the PE | plasticarmyman | enTourage eDGe | 16 | 06-11-2012 07:08 PM |
Seriously thoughtful I always knew Windows was a WIP | GeoffC | Lounge | 4 | 02-06-2010 02:20 AM |
Thirty - WIP - comments wanted | ravenlife | Writers' Corner | 20 | 08-16-2009 12:10 PM |
Opinions needed on a WIP ebook | Nate the great | Workshop | 5 | 07-15-2009 11:38 AM |