View Single Post
Old 01-27-2013, 04:34 AM   #34
giorgio130
Time Waster
giorgio130 ought to be getting tired of karma fortunes by now.giorgio130 ought to be getting tired of karma fortunes by now.giorgio130 ought to be getting tired of karma fortunes by now.giorgio130 ought to be getting tired of karma fortunes by now.giorgio130 ought to be getting tired of karma fortunes by now.giorgio130 ought to be getting tired of karma fortunes by now.giorgio130 ought to be getting tired of karma fortunes by now.giorgio130 ought to be getting tired of karma fortunes by now.giorgio130 ought to be getting tired of karma fortunes by now.giorgio130 ought to be getting tired of karma fortunes by now.giorgio130 ought to be getting tired of karma fortunes by now.
 
Posts: 422
Karma: 289160
Join Date: May 2011
Device: Kobo Glo and Aura HD
Quote:
Originally Posted by KevinShort View Post
So what exactly have you managed to do so far?
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!
giorgio130 is offline   Reply With Quote