Qt Platform for Kindle 2 & DX, plus Sudoku! - Page 2

darron · 02-02-2010, 11:13 AM

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, 08: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, 06: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, 04: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, 09: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, 10: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, 03: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, 10: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...

)

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

Quote:

Originally Posted by darron

... 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, 12: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, 08: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.

Quote:

Originally Posted by darron

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, 07: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, 08:52 PM

Very interesting thread, even for technically challenged like me

cdisou · 02-23-2010, 09: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.

frediz · 03-18-2010, 03: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, 01: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?

02-23-2010, 09:44 PM	#28
cdisou Junior Member Posts: 4 Karma: 10 Join Date: Sep 2009 Device: Kindle DX	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. Last edited by cdisou; 02-23-2010 at 11:03 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
PRS+: Enhanced firmware for Sony Reader, Folders, Games & more	kartu	Sony Reader Dev Corner	4192	05-15-2020 11:42 AM
Ended M-Edge Platform Jacket & eLuminator2 for Kindle 2	simplyparticular	Flea Market	2	07-08-2010 11:43 PM
Gizmodo & GigaOm on Kindle as a Platform	kjk	News	5	07-04-2010 06:16 PM
Annotations & cross platform..	fragile	Other formats	0	04-21-2010 01:04 PM
$0.01 in Kindle Store: Interactive Sudoku for Kindle 2 and Kindle DX - Volume 1	Xia	Deals and Resources (No Self-Promotion or Affiliate Links)	2	11-07-2009 10:06 AM

02-02-2010, 11:13 AM	#16
darron Enthusiast Posts: 30 Karma: 2600 Join Date: Dec 2009 Device: Kindle DX	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).

02-03-2010, 08:30 PM	#17
DairyKnight Connoisseur Posts: 63 Karma: 2600 Join Date: Oct 2008 Device: PRS-505	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.

02-04-2010, 06:31 AM	#18
Lemming Member Posts: 13 Karma: 10 Join Date: Nov 2008 Device: Various	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 :-)

02-04-2010, 04:42 PM	#19
darron Enthusiast Posts: 30 Karma: 2600 Join Date: Dec 2009 Device: Kindle DX	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.

02-04-2010, 09:36 PM	#20
darron Enthusiast Posts: 30 Karma: 2600 Join Date: Dec 2009 Device: Kindle DX	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...

02-04-2010, 10:29 PM	#21
darron Enthusiast Posts: 30 Karma: 2600 Join Date: Dec 2009 Device: Kindle DX	... 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)

02-05-2010, 03:08 AM	#22
Lemming Member Posts: 13 Karma: 10 Join Date: Nov 2008 Device: Various	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.

02-07-2010, 12:25 AM	#24
darron Enthusiast Posts: 30 Karma: 2600 Join Date: Dec 2009 Device: Kindle DX	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.

02-07-2010, 07:46 PM	#26
darron Enthusiast Posts: 30 Karma: 2600 Join Date: Dec 2009 Device: Kindle DX	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).

02-08-2010, 08:52 PM	#27
angelad Groupie Posts: 163 Karma: 64 Join Date: Jun 2009 Device: kindle dx	Very interesting thread, even for technically challenged like me

Advert

Advert

03-18-2010, 03:30 AM	#29
frediz Member Posts: 14 Karma: 10 Join Date: Mar 2009 Device: prs 505	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

04-06-2010, 01:14 PM	#30
Ramblurr Member Posts: 11 Karma: 10 Join Date: Apr 2010 Device: Kindle	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?