View Full Version : Qt Platform for Kindle 2 & DX, plus Sudoku!


darron
01-30-2010, 02:53 AM
Okay, so here it is! (http://www.griffin.net/2010/01/hacking-the-amazon-kindle-dx-part-2-qt-and-sudoku.html)

QtEmbedded compiled for the Kindle, all packaged up for the Kindle 2 and DX (thanks to the great package tool by Igor and Jyavenard)

I've only been able to try this out with v2.3 software. It's also only been able to try it on a Kindle 2 Global Wireless and a Kindle DX U.S. Wireless. It seemed to work, but there are no guarantees (and the next update could easily cause a problem).

Normal disclaimers about bricking your Kindle apply.

The Qt platform and plugins are free to use for Kindle app development. I'll be putting up a simple sample app with source code and a few scripts to go along with the packager soon.

I'm also including a Sudoku game, which is really great for this platform.

Please let me know how it goes for you.

Darron

jft
01-30-2010, 04:58 AM
:thumbsup: :thanks:

I didn't even know there is an edition for the framebuffer :blush: Let's see how difficult it is to write a simple text editor and to handle the update area right :cool:

Edit: And I wasted the last week toying with the java framework on the kindle *argh*

jft
01-30-2010, 06:06 AM
F***. Can't wait to start programming :) Also saw, that there is a texteditor demo included in the embedded SDK.

So your HotkeyManager implements Pointer Management, Display Management and Character Input and all I have to to is write an app, start it with the -qws -display KindleFb option as client and I am done. Right?

whitepaper
01-30-2010, 06:25 AM
This is good work! Any efforts in building a more universal runtime on DX is attractive. Does this mean there is a clear layer for E-Ink display manipulation? It looks like some other guys also had made improvements on this, but there is still no clear API revealed.

Also it is interesting to see what SDK can be released by Amazon later, it should be not so powerful that QT ..

darron
01-30-2010, 11:25 AM
jft: yeah, that's about it. Just copy the su.sh hotkey script in /usr/local/Trolltech/hotkey-scripts to some other hotkey combination, and point to your app.

The fiveway as a pointer is pretty bad. It's a worse hardware interface than the keyboard in that the keyboard at least can track multiple keys at once. The fiveway will release say the up key when it starts with the left key... so you can't even go diagonally. I tried to implement a little pointer acceleration, but the delay with the screen updates makes it pretty hard to use.

A generic text implementation would need some popup menu for the symbol key... I don't implement that in the keyboard driver. About the only place Sudoku would have benefited was the save game text boxes, so I haven't done that yet. I may take a stab at it in the same app.

You can do whatever you want with the screen now.

The only serious limitation is really in that the Java framework currently has to be shut down and restarted when you quit your app. It'd be nice if there was a little Java booklet that would let you select apps, and throw up a blank screen that never updated so the framework wouldn't have to be killed... although making sure it quit last and allowed the home screen to repaint correctly might be a little tricky. I also thought about altering the display, keyboard, and fiveway Linux drivers to allow one handle to disable all the others temporarily...

I also don't currently have any hooks into notification that the device is going to sleep. Without the framework, there's no screensaver. So, it could look to the user like it locked up. Sudoku throws up a "your Kindle may be asleep" screen at 4 minutes and 50 seconds without keyboard activity.

If you forget to wire up your script correctly, then F + W does that for you. N + F if you forget to shut it down first.

darron
01-30-2010, 08:30 PM
Okay, It made Slashdot.org (http://developers.slashdot.org/story/10/01/30/1924200/Unofficial-Qt-Environment-and-Sudoku-For-the-Kindle?art_pos=4)!

How's it working for people? I need to know if it's horribly broken pretty soon now! :)

kawaisoonano
01-31-2010, 12:17 AM
can anyone tell me what the advantage with applying QT platform?
just to play shudoku game?

darron
01-31-2010, 01:45 AM
Well, Sudoku is written for Qt, so it's required if you want to try it out. Qt is simply a great library programmers can use to help them write applications.

The thing here is that the Qt library was made to work on the Kindle, and that in turn was used to make Sudoku. There will probably be at least a few more apps using it from other people in a while.

If you don't care much about Sudoku, and you aren't a programmer... I'd wait until there was a more compelling reason to potentially void your warranty. Let some early adopters figure it out, improve on it...

jft
01-31-2010, 04:40 AM
Sorry no progress here atm. Tried to build my own cross compiling toolchain yesterday but no success (somebody noticed there isn't an arm target in the glibc 2.5 library supplied by amazon??) So I will also use scratchbox.

Are you thinking about publishing the code of your drivers? Or do you have a vcs hosting the code somewhere? I think it would be great to have an organised platform so other can contribute to that project and improve it. At least I am interested :D

darron
01-31-2010, 12:13 PM
I'm going to publish the keyboard and fiveway code, that's almost a certainty. We'll see about the e-ink plugin.

The keyboard and fiveway code could use some work. They're bare bones right now. The keyboard obviously could use a popup for the SYM key, for starters.

I've got a little bit to work on first, but I'll set up probably a SourceForge project in a few days/weeks.

DairyKnight
02-01-2010, 02:03 AM
This is great work!

If possible, I'd like to learn more about how the e-ink driver was implemented.
Porting qt embedded to Kindle is not really a new thing, and someone has already done this (http://code.google.com/p/qindle/ - seems this project's dead). But fully functional e-ink driver and keyboard with sample program is a true breakthrough.

Hope details would be published soon. And more people would join the Kindle development community. It'll be cool to see programs like Poppler ported to Kindle. :cool:





Okay, so here it is! (http://www.griffin.net/2010/01/hacking-the-amazon-kindle-dx-part-2-qt-and-sudoku.html)

QtEmbedded compiled for the Kindle, all packaged up for the Kindle 2 and DX (thanks to the great package tool by Igor and Jyavenard)

I've only been able to try this out with v2.3 software. It's also only been able to try it on a Kindle 2 Global Wireless and a Kindle DX U.S. Wireless. It seemed to work, but there are no guarantees (and the next update could easily cause a problem).

Normal disclaimers about bricking your Kindle apply.

The Qt platform and plugins are free to use for Kindle app development. I'll be putting up a simple sample app with source code and a few scripts to go along with the packager soon.

I'm also including a Sudoku game, which is really great for this platform.

Please let me know how it goes for you.

Darron

darron
02-01-2010, 02:27 AM
I just updated my download page to include a sample project. You'll need a cross-compiling environment to use it. (Scratchbox works well) It's got some simple packaging script and a hotkey (D + M for demo) to run once installed.

jft
02-01-2010, 10:31 AM
Got everything working. Even the demos work like a charm. I haven't found a README in your packages describing the keymap.

So for everybody else:

Home -> Home
Prev -> Page Up
Next -> Page Down
Back -> Backspace
Menu -> Menu
Sym -> Tab
aA -> Super L

Only modifier is Shift.

The problem with the framework is kind of frustrating. Just an idea:

I think it is possible to change the name for the /dev/input devices - lets say event[23]. Now our hotkey_manager listens on them and retrieves all the events. If there are other qws clients just the app gets the key events. If there is no other client we pipe the original data into our named pipes /dev/input/event[01]. So we stop the framework form interfering with our Qt apps but have a working framework after Qt app shutdown.

jyavenard
02-01-2010, 06:28 PM
Sorry no progress here atm. Tried to build my own cross compiling toolchain yesterday but no success (somebody noticed there isn't an arm target in the glibc 2.5 library supplied by amazon??) So I will also use scratchbox.


For the toolchain ; use
OSELAS.Toolchain-1.99.3/arm-1136jfs-linux-gnueabi/gcc-4.1.2-glibc-2.5-binutils-2.17-kernel-2.6.18 built with

http://www.oselas.com/software/ptxdist/download/v1.99/ptxdist-1.99.11.tgz
http://www.oselas.com/software/ptxdist/download/v1.99/ptxdist-1.99.11-patches.tgz
http://www.oselas.com/oselas/toolchain/download/OSELAS.Toolchain-1.99.3.1.tar.bz2

You could also use the buildroot tools ; everything is automated ; no need to worry about the 3 stages of GCC compiling etc...

darron
02-02-2010, 12:52 AM
I'm going to be pretty busy in the near term... but is there anything that would help you guys out? I'm waiting on some stuff to happen before I release any plugin code. I'm also almost totally reworking the keyboard plugin to be easily portable to other platforms.

You seem to have the toolchain down (I assume, it's different than mine)

Does the hotkey stuff make sense?

There's something minor wrong with the e-ink plugin, I think... the sample project doesn't update the screen properly the very first time. I forced the background to change a few times to sort of hide that. :) If anyone's noticed problems with simple paintEvent() style QMainWindow classes that's the culprit. The current big ugly hack is to have a counter and force the background to change once or twice after the app first starts. Subwidgets on the main window don't seem to have this problem.

Just some quick notes/thoughts:

I'm installing apps in the /usr/local/Trolltech/apps folder. Maybe it should be something else besides "Trolltech", but that directory is required by the default QtEmbedded compile... so I just used that. (That path can be changed by command-line options to configure, but that looks long and possibly error-prone, so I didn't mess with it) My current system is for single-file apps to go in that folder directly, and for apps with data to have a single subdirectory there (for easy uninstalls).

QSettings is a great class to use for easily persisting state. I'm using the IniFormat of that, and putting app data in /mnt/us/system-kindleqt/etc.

The uninstall_qt package blows away -everything-, at the moment. It destroys /mnt/us/system-kindleqt and /usr/local/Trolltech, and pulls the /etc changes. The /mnt/us/system-kindleqt/etc folder may be better off in a location safe from deletion... but if they're removing this stuff for software update purposes I decided extreme prejudice was the way to go.

darron
02-02-2010, 12:13 PM
jft: The event renaming idea is a good one, and much better than what I had in mind (which I probably wasn't going to do, at least any time soon)... which was to try to figure out how to recompile the kernel modules and add some way to disable things in there.

It should work. We just need a startup process that runs before the framework starts up, which renames those events (probably to something with no chance of a collusion, like eventKeyboardHook and eventFiveWayHook). Then we can try to create pipes for event[01] and do what you said with selectively passing on input events (if that's sufficient, and something in the code layer doesn't try to check it for device major/minor numbers...)
If something DOES want a real device, a passthrough device can probably be done without a whole lot of trouble. (Is there already such a thing? It seems like a potentially common enough need) Certainly less trouble than trying to modify the input device modules themselves.
If, however, something in the framework actually looks for the device major/minor numbers... then we have to change the actual modules themselves. (Unless there's a way to load devices at a different major number?)
The startup script would have to be very careful not to rename the device files if any part of the replacement system was missing or didn't work (or didn't uninstall cleanly).

DairyKnight
02-03-2010, 09:30 PM
I didn't try your program but it seems you didn't make any modifications to the QTE library itself? Using simply direct FB is a very ineffective way of utilizing the e-ink display. So far as I can see from the reverse-engineered Java code, there're at least 3 ways of updating the display: total refresh (the black-white-out), redraw without refresh, and areal refresh.

There is actually a program shipped with Kindle (cannot remember the name) which demonstrates what I talked about in the above. I believe the Qindle developer did a better job in integrating the framework with Kindle DX hardware. And I just saw they've uploaded a modified okular for PDF reading.

Lemming
02-04-2010, 07:31 AM
Quindle looks great and I'd love to try it, but there's zero documentation. Maybe the two projects could be integrated? It seems crazy to have two groups working on basically the same thing. Certainly Okular looks interesting, I'd love to have decent PDF navigation, but even as a developer I'm not willing to waste the time it would take me to get Quindle going based off one page of documentation in Chinese :-)

darron
02-04-2010, 05:42 PM
Err, there's no modification to QTE itself, but I did write plugin drivers for the e-ink screen, keyboard, and fiveway.

I saw the different update methods from the e-ink device driver source code. The e-ink plugin is using device driver ioctls and only updates the part of the screen that is actually changing. It also doesn't update at every blit to the screen, but only later once dirty regions are calculated.

darron
02-04-2010, 10:36 PM
I looked at qindle a little this evening. It's a little hacky. Just a suggestion or two:

Qt/Embedded is well designed... if you need to support a new device, don't hack up the Qt library code. Make your own plugin. I made a class derived from QLinuxFbScreen, so I only had to overload the functions that actually changed (not much). I also made plugins in the same way for the keyboard and mouse, and didn't resort to hacking up the "usb" keyboard device. (Do all the keys work in qindle? It doesn't look like they handle them all. Well, maybe you have to re-translate in the app... which would be ugly as hell)

That said, considering the way they're updating the display, they must not have the inverted palette problem I do. I have to use a flag 'fx_invert' to tell the driver my framebuffer data is inverted.

Because I'm using 'fx_invert', I can't use 'fx_partial', which doesn't do the refresh stage.

Someday I'll get around to fixing my palette, and then I could provide a means of skipping the refresh stage for faster updates.

It looks like they just update whatever region is passed in to setDirty(). On Sudoku, this was almost the whole screen, every time. (Okay, partially the app's fault... but that's probably very common)

I added code that keeps track of the last framebuffer contents, and searches for the bounding rectangle of the actual changes... and I only send that rectangle to the e-ink framebuffer driver for update. It's much, much faster. I also pass the update data in a structure to the driver using ioctl(). (Not a text buffer using sprintf)... but there's probably virtually no performance difference there.

I tried a Qt terminal emulator program before I added the framebuffer tracking code, and it updated the whole screen so often it was totally unusable. I should go back and try it now.

Okular is supposed to use Poppler for PDF... I don't see any of the massive dependencies that Poppler has in the sample. So, they must not actually have PDF support. ????

I'm not surprised... the dependency list for Poppler is monstrous...

darron
02-04-2010, 11:29 PM
... Poppler's dependencies: fontconfig, freetype, zlib, libjpeg6b, openjpeg, libpng, cmake, libxml2.

maybe binutils. I don't remember why I have that.

Does anyone know how to contact someone in Amazon that I can talk to? There is a thing or two I really want to get permission for. (it's worth a shot)

Lemming
02-05-2010, 04:08 AM
Poppler does seem to be the PDF rendering engine of choice - it's used on the iRex devices, for example, and it comes with code to integrate into Qt (see http://doc.trolltech.com/qq/qq27-poppler.html). Given the complexity of rendering PDFs correctly I'm actually surprised the dependency list is that small.

DairyKnight
02-06-2010, 11:53 PM
Yes you're right. Okular depends on Poppler and lots of other things. I didn't try out that code, but I've seen the developer of Qindle posted a screenshot with Okular running on Kindle somewhere (which I cannot find now... :blink:)

Don't really think you'll get any luck by asking Amazon... especially now they're publishing their own SDKs...

... Poppler's dependencies: fontconfig, freetype, zlib, libjpeg6b, openjpeg, libpng, cmake, libxml2.

maybe binutils. I don't remember why I have that.

Does anyone know how to contact someone in Amazon that I can talk to? There is a thing or two I really want to get permission for. (it's worth a shot)

darron
02-07-2010, 01:25 AM
SDK? Well, here's the thing.

Amazon could and should provide as many ways to get apps on the Kindle as possible. They need Qt.

If Amazon is releasing a SDK based on the same embedded Java that's on the Kindle now, then they might as well just cut off a leg and tie one hand behind their back.

Embedded Java is awful. It's been on many, many phones for years and years... way before the iPhone. Nobody coded for it. Now, some of that was simply boneheaded barriers to entry, but there was never really a good platform there to code to.

My most recent experience with it was trying to port a modern Java Sudoku generator to it... major language features were missing on the embedded side (Generics, etc). It would probably have been easier to simply port it to C++.

I loved Java back when all I needed to be happy was a better graphics platform than Microsoft's GDI. My standards are much higher now.

There's a great enterprise niche for Java, but it has always sucked at embedded. Embedded Java is a serious mistake.

At least have the decency to run a full, modern Java. The Kindle looks like it can handle it.

Oh well. I guess the only chance they have is to maintain a much better ebook selection and lower prices than Apple.

DairyKnight
02-07-2010, 09:16 AM
I agree with you that Qt is a great platform. E-Ink Readers lik Onyx Boox is already based on qt & qtopia.

But I hold my own opinions about Java. Embedded Java has been there for a while and it has been evolving all these years. Well I don't want to start a meaningless fight about which platform is better here... so anyway, for Amazon, that's what they've chosen and it doesn't seem that they'll change everything from Java to Qt just for a better SDK. And we'll have to live with it.

For the SDK, the apps you can develop is highly restricted. No apps such as readers and players could be developed. So I suppose they'll make some interfaces as private, e.g. file handling.

iPad and Kindle basically use different technologies so it's hard to compare. Apparently Kindle is more eye-friendly and has longer battery life, however, iPad's better at handling multimedia contents and is more powerful.
Guess the thing Amazon really needs is to improve the PDF reading experience, and add support for other formats such as epub, ppt and doc. I can see that lab126 is hiring PDF engineers. :)


SDK? Well, here's the thing.

Amazon could and should provide as many ways to get apps on the Kindle as possible. They need Qt.

If Amazon is releasing a SDK based on the same embedded Java that's on the Kindle now, then they might as well just cut off a leg and tie one hand behind their back.

Embedded Java is awful. It's been on many, many phones for years and years... way before the iPhone. Nobody coded for it. Now, some of that was simply boneheaded barriers to entry, but there was never really a good platform there to code to.

My most recent experience with it was trying to port a modern Java Sudoku generator to it... major language features were missing on the embedded side (Generics, etc). It would probably have been easier to simply port it to C++.

I loved Java back when all I needed to be happy was a better graphics platform than Microsoft's GDI. My standards are much higher now.

There's a great enterprise niche for Java, but it has always sucked at embedded. Embedded Java is a serious mistake.

At least have the decency to run a full, modern Java. The Kindle looks like it can handle it.

Oh well. I guess the only chance they have is to maintain a much better ebook selection and lower prices than Apple.

darron
02-07-2010, 08:46 PM
I'm not planning to argue platforms here any further, either. I pretty much said what I needed to say.

I'm not saying Amazon should drop Java for Qt this instant... they obviously have been working on the SDK a while, so they should release what they've got.

There's nothing to stop them from providing both, though. They'd get maybe 50-75% more developers that way. After a while, it'd become clear what platform the developers preferred.

Android uses Java (sort of). Even with that, they saw enough use for a C/C++ SDK (or NDK, as they call it).

angelad
02-08-2010, 09:52 PM
Very interesting thread, even for technically challenged like me :(

cdisou
02-23-2010, 10:44 PM
Hello to all! I'm the owner of project Qindle. There is a new version of qindle(0.0.3), which doesn't need installation and won't affect the system. If you have usbNetwork installed, just download qindle from http://qindle.googlecode.com/files/local.tar.bz2 and extract into Kindle's flash drive. Then, by executing `usbNetwork twice(the first time usbnetwork starts normally), the new system starts.

Sorry for the shortage of document, I'm working on it. Any suggestions are welcome.

http://www.hi-pda.com/forum/attachment.php?aid=656580&noupdate=yes

frediz
03-18-2010, 04:30 AM
Hi,

Darron, do you plan to release your eink qt enhancements anytime soon ?
I thought that may interest you :
http://qt.gitorious.org/qt/qt/merge_requests/417

Looking forward to hear from you :)

Ramblurr
04-06-2010, 02:14 PM
After installing Qt embedded on the kindle, will reseting it to factory defaults still work as expected?

that is if a new conflicting software update is pushed by amazon, can we reset and then update to the latest version?

darron
04-09-2010, 10:20 AM
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
04-10-2010, 01:45 AM
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
05-31-2010, 04:53 PM
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
08-24-2010, 08:04 PM
@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 (http://yfrog.com/f/86kdxgj/)) 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
08-24-2010, 09:12 PM
Another QT Embedded:
Qindle (http://mobileread.com/forums/showthread.php?t=94483) 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
08-27-2010, 10:55 AM
@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 (http://yfrog.com/f/86kdxgj/)) 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
08-27-2010, 11:49 AM
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/hacking-the-amazon-kindle-dx-part-2-qt-and-sudoku.html

Dzha
08-27-2010, 02:43 PM
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/hacking-the-amazon-kindle-dx-part-2-qt-and-sudoku.html

Thanks a lot, darron! :thanks:

h1uke
08-27-2010, 11:10 PM
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 (http://www.mobileread.com/forums/attachment.php?attachmentid=54872&d=1278700161).
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
08-27-2010, 11:28 PM
(That should be --DXg (or --dxg), I made a dumb typo in the help msg ;).)

Dzha
08-28-2010, 04:20 PM
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
10-20-2010, 09:56 AM
@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
10-24-2010, 03:39 PM
@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
10-24-2010, 08:41 PM
@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
10-25-2010, 09:20 PM
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 :angry:. 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?

Dzha
10-26-2010, 09:44 AM
@darron
I have stumbled across KindleScreen implementation in KindlDirectFB directory. It looks like an attempt to inherit KindleScreen directly from QScreen and do the blit/solidFill etc at low level skipping QLinuxFbScreen. It looks very interesting.
I wonder if I should even look that way with my amateurish skills in Qt! But ... can you please, tell me a little more about this plugin? Do you think it is possible to re-use the code and speed up painting operations? Or the gain will be negligible?

Dzha
10-29-2010, 07:06 AM
I was thinking about a solution for a while now. Ideas so far:

Solution 1: Patch QScreen (easy?)

introduce virtual void QScreen::setFlashing(bool)
empty default implementation
overwrite setFlashing in KindleScreen
set the flashing update once when the set to true and reset to false after the update
get the static pointer QScreen::instance();
use screen->setFlashing(true) before calling the update to do one flashing update


Solution 2: Intermediate class (better?)

inherit QFlashingScreen from QLinuxFBScreen
Introduce setFlashing in QFlashingScreen
reinterpret_cast or dynamic_cast the pointer of QScreen to QFlashingScreen
call setFlashing()
enjoy flashing udpate


I think that I can possibly use QFlashingScreen in future for some other purposes as well (like hardware text cursor for example). So No2 looks good so far.

http://img833.imageshack.us/img833/8708/refreshqt3.jpg (http://img833.imageshack.us/i/refreshqt3.jpg/)

Uploaded with ImageShack.us (http://imageshack.us)

Edit:
Victory is sweet!
Implemented in 10 minutes, works like a charm :).

Hans Hoogendoorn
10-29-2010, 12:31 PM
Hi there, Could anyonde inform me whethet Calibre has been brought up to date for the new Lindle DX?
Thanks in andvance Hans

ableeker
12-04-2010, 11:00 AM
Hi!

Is there a package that will install on the DXG?

Thanks!

ableeker
12-05-2010, 03:50 PM
Right, I was successful in installing the packages on my DXG after repacking them with version 0.11 of the packaging tool (found it in this mobilread forum), but now I've hit another snag, the hotkeys don't seem to work. Nothing happens when I press 's+u' (press s, hold s, press u, release both s and u), or 's u' (press s, release s, press u, release u). The other key combinations do nothing either, not even r+s+t, which is supposed to reboot the Kindle, and should be quite noticeable.

What is supposed to happen anyway? Am I doing something wrong? I've installed the jailbreak first, does this work without it? And if I want to install the packages on the Kindle DXG, should I use the US, or the international version?

Thanks