Qt Platform for Kindle 2 & DX, plus Sudoku!

[darron]

I don't think the Kindle has a proper factory defaults reset that includes a clean filesystem. So, I wouldn't expect that to work. If that was the case, then the several threads asking for help to recover a Kindle wouldn't exist. (or at least they'd be very short )

Someone please correct me if I'm wrong.

If an update fails, the best thing I can think of would be to uninstall any additions you've put on it and either wait for another update attempt or go download and run the update manually.

[Ramblurr]

Yea, I didn't realize Amazon made the firmware available. Looking at the various hacks and other update*.bins out there for the kindle it looks like the update process is incremental. That is, it only updates the changed files.

Does there exist a firmware package that contains a backup of the entire system? I suppose it would be easy to create with dd, but difficult to distribute.

I'm setting up my cross compilation dev environment setup now, very excited to start coding up some qt toys for my dx.

Have you considered releasing your source for the device drivers? Using Qt I think a real alternative to Amazon's Java ui could be developed. Would be a lot of fun.

[Saruman]

Has anyone continued with Qt on kindle? A Qt-SDK would be very useful in spite of the hopefully comming KDK because some people beliefe in C/C++ .

[Dzha]

@darron

Hi, there is a group of people on the-ebook.org trying to port FBreader to Kindle. Apparently the first attempt was successful (proof) and we are all excited about it.

Some time ago you were going to publish the sources of your qt plugins/drivers. Did you actually do it? In case you didn't, would it be possible for us to use the sources (on your conditions, of course).


We would really appreciate your help.

[meem]

Another QT Embedded:
Qindle A Qt port with Rich Text Editor, Web browser (Arora), MP3 player, And PDF-DJVU-EPUB-CHM viewer (Okular).

http://mobileread.com/forums/showthread.php?t=94483

[darron]

Originally Posted by Dzha

@darron

Hi, there is a group of people on the-ebook.org trying to port FBreader to Kindle. Apparently the first attempt was successful (proof) and we are all excited about it.

Some time ago you were going to publish the sources of your qt plugins/drivers. Did you actually do it? In case you didn't, would it be possible for us to use the sources (on your conditions, of course).


We would really appreciate your help.

This sounds great!

I was thinking I'd eventually get back to cleaning up the code and migrating improvements from the Palm Pre plugin back into the Kindle one, but that's just not going to happen any time soon. So, I'll package up the code as it is and release it now.

The code is LGPL, and I'd ask that any direct derivatives of the plugins remain the same.

I believe one outstanding issue is the screen inversion. I'm currently updating the Kindle with an inverting copy (fx_invert), but if the Kindle refreshes the screen directly from the framebuffer it will be drawn normally and become inverted. So, it needs some kind of fixed color map, or tweaking at the blit implementation.

However, plugins are a MUCH cleaner solution than the Qindle port (unless they went back and redid that the right way, in which case that might be a better starting point) The QWS screen/mouse/keyboard plugin API was, after all, specifically designed into Qt for exactly this kind of task.

[darron]

I've updated the blog page to link to the plugin source code. I've also put up test packages using an updated packager, and a build folder with compiled plugins, scripts, and the packager used to build the packages.

http://www.griffin.net/2010/01/hacki...nd-sudoku.html

[Dzha]

Originally Posted by darron

I've updated the blog page to link to the plugin source code. I've also put up test packages using an updated packager, and a build folder with compiled plugins, scripts, and the packager used to build the packages.

http://www.griffin.net/2010/01/hacki...nd-sudoku.html

Thanks a lot, darron!

[h1uke]

Originally Posted by darron

I've updated the blog page to link to the plugin source code. I've also put up test packages using an updated packager

Thank you very much for providing the plugin source code!

However, newer packages still do not work for the latest Kindle DX Graphite.
First of all, the latest packaging tool v.0.9 should be used, it can be found here.
Then, the --DXG ftag should be used when creating the package specifically
for Kindle DX Graphite running the v2.5.5 firmware.

A simple shell script below can be used in order to simplify repackaging
for a different target:

#!/bin/sh
usage()
{
    echo "repkg.sh -- repackages the update_'basename'.bin package for use on 'target' device"
    echo "Usage: ./repkg.sh 'target' 'basename'"
    echo "   example: ./repkg.sh dxg install_qt_dxu"
    return ;
}

if [ $# -lt 2 ]; then
    usage
    exit 1
fi
./kindle_update_tool.py e update_$2.bin
./kindle_update_tool.py m --$1 --sign $2-$1 update_$2.bin.tgz
rm -f update_$2.bin.tgz

it is implied that either the packager and the original package are residing
in the same(current) directory. Applying

 
./repkg.sh dxg install_qt_dxu

will unpack the update_install_qt_dxu.bin and repack it into the update_install_qt_dxu-dxg.bin
which can be used on DX Graphite running the 2.5.5 firmware.

Hope this helps,

h1uke

[NiLuJe]

(That should be --DXg (or --dxg), I made a dumb typo in the help msg .)

[Dzha]

I tried to build qt 4.6.3 with eldk environment for arm. Fist time the build failed with missing endian parameter error. So I was not sure if I should use -big-endian or -little-endian. The primary target is Kindle DXg that has ARM11 architecture (ARM1136JF-S). Apparently it supports both endians depends on how the processor is connected. Does anyone know how it is done on Kindle?

Edit:
I have got the answer, it is little-endian, but it seems better to use -xplatform option with configure and it will take care of the endian option. Example that was given to me on the-ebook.org forum:

./configure -embedded arm -xplatform qws/linux-arm-g++ -opensource -prefix /opt/qt4ARM -nomake examples -nomake demos

[Dzha]

@darron
I hope you are still notified of new messages on this thread.

We are using your screen plugin for the new kindle port of FBReader and currently trying to improve the screen refresh. At this moment we can run the plugin either the flashing mode or in non-flashing mode. I've come up with the idea of having the plugin that will combine them, i.e. on page turning event the app will do the full screen flashing update, in all other cases it will only do partial. If you look at original Kindle firmware you will notice similar behavior, most artifacts are accumulated on the screen if the flashing refresh is not performed when the page has been turned over a few times.
So the app should tell the plugin what kind of refresh to perform. I've only started using qt a few weeks ago, so excuse me if I am not seeing the obvious:! My current idea is the following:
- inherit a new class from QLinuxFbScreen and create blitFull (similar to blit)
- overload blitFull in KindleScreen class with the function that will call ioctl with full refresh
- inherit a new class from QWidget and create fullRepaint() (similar to repaint()) and paintEventFull() (similar to paintEvent())
- inherit a new class from QPainter and link that to blitFull (whole link between repaint of the widget and drawing classes is unclear for me at this point, but I will figure this out )

A widget derived from the new widget class should have repaint() and fullRepaint() available and they will eventually perform partial/full refresh.
Well the whole design looks a little complicated and I am sure there is a simple and straightforward way to accomplish the same task.

What do you think?

[darron]

@Dzha: Sounds good except I'm not sure about a new QLinuxFbScreen. You could just add the full refresh function to the screen from my package, and use the static QScreen::instance() function to get a pointer to it. In your case, it'd be safe to simply cast that instance pointer to the Kindle screen version from the package, and use that.

I think in testing I was doing this sort of thing for the mouse pointer... setting the refresh mode, drawing the mouse pointer, resetting the mode, etc. I didn't bother with a custom QWidget/QPainter... the paints were synchronous at that point.

[Dzha]

Originally Posted by darron

@Dzha: Sounds good except I'm not sure about a new QLinuxFbScreen. You could just add the full refresh function to the screen from my package, and use the static QScreen::instance() function to get a pointer to it. In your case, it'd be safe to simply cast that instance pointer to the Kindle screen version from the package, and use that.

I think in testing I was doing this sort of thing for the mouse pointer... setting the refresh mode, drawing the mouse pointer, resetting the mode, etc. I didn't bother with a custom QWidget/QPainter... the paints were synchronous at that point.

Thanks a lot darron.

It looks like the best way is to use QScreen::instance(), cast the pointer to our driver and then call the new method. Also it should be possible to call the new function within the existing paintEvent().
The only problem now is that I need to link my app with the plugin. I should be able to figure it out. At list I found a "How to.." on Qt plugins and it recommends an abstract interface class use.
Also I have been thinking on how to speed up the process of drawing the gui elements. Menu looks ok, but for example the drawing of the preferences dialog is a drag. I am not sure that it is possible to accelerate that through hardware somehow, probably not. I will definitely try to simplify dialogs as much as possible, remove all decorations, etc.

[Dzha]

Somehow can not make this work:

		
                QPluginLoader loader();
		QObject* object = loader.instance ();

		kindleScreenInterface = qobject_cast<KindleScreenInterface*> (object);
		/*if(kindleScreenInterface!=0)*/
                kindleScreenInterface->fullBlit();

In the plugin I have defined an empty function fullBlit() for testing, but it's crashing . I have declared KindleScreenInterface as pure virtual and used Q_DECLARE_INTERFACE macro, also in the definition of KindleScreen I used:

    Q_OBJECT
    Q_INTERFACES(KindleScreenInterface)

Looks like kindleScreenInterface is not getting the right pointer. I am not sure how to find the screen plugin that is automatically preloaded by QWS (I think). I could not find a global pointer to the screen plugin. I have tried to cast QScreen::instance(), but it did not work either:

		QObject* object = (QObject*)QScreen::instance();

		kindleScreenInterface = qobject_cast<KindleScreenInterface*> (object);
		//if(kindleScreenInterface!=0)
         	kindleScreenInterface->fullBlit();

Completely confused now. Need to look into how Qt loads the screen plugin.

Edit: a thought about the order of initialization in multiple inheritance: QObject should be initialized first! So this will not work:

 
 class KindleScreen : public  KindleScreeIniterface, QLinuxFbScreen, QObject {
Q_OBJECT
...
}

... but this should work :

 class KindleScreen : public QObject, KindleScreeIniterface, QLinuxFbScreen{
Q_OBJECT
...
}

I will try this in the evening.
Edit: it did not help at all. Thoughts:
* QScreen is not inherited from QObject, so qobject_cast will not work
* I need to cast the QObject related to the new interface
* plugin exposes the ScreenPlugin class by Q_EXPORT_PLUGIN2(KindleFb, ScreenPlugin) and retuns the KindleScreen object (as QScreen) from create(), does it mean that KindleScreeIniterface could not be located?