Kindle Paperwhite = 5.2.0

[ixtab]

So, I just learned this from here:

- Paperwhite serial numbers: B024 (Wifi), B01B (Wifi+3G)
- Firmware version: Kindle 5.2.0 (1729740065)

This is pretty much what I expected. Although there seem to be some serious UI changes wrt 5.1.0, it's still just an evolution of the "old" K5 firmware, not a complete revolution.

This also means that hopefully, many of the previous hacks & patches for the Kindle Touch can be ported (and hopefully with relatively little effort) to the PW. And maybe we don't even have to reinvent the wheel for the jailbreak either? We'll see.

Note: I don't have a PW yet. I expect mine to arrive here in about 4-6 weeks.

[techiemonkey]

Does this mean that kindle touch development will stop?

[ixtab]

Originally Posted by techiemonkey

Does this mean that kindle touch development will stop?

What makes you think that? Has development for the K3 stopped because there are K4 and K5 models out there?

I personally will certainly shift focus in the beginning, because I want to get my own stuff running on the PW. But ideally, things will work both on the K5 and the PW. Depending on how different the firmwares really are, this may result in more or less effort.

Maybe (speculation!) it's even possible to run the 5.2.0 firmware on the K5 - or maybe not. We'll see.

[geekmaster]

Originally Posted by techiemonkey

Does this mean that kindle touch development will stop?

I try to make my stuff run on all kindles I have, including DX/DXG/K3/K4/K5, and soon Paperwhite. I even plan to make it work on my Nook Simple Touch (some day), without recompiling the executable. At least that is what I want. That is why I like static builds.

EDIT: Considering the fact that I have a bunch of K5 demos arriving soon, I do not plan to stop developing for the K5. In fact, I am working on adding dithering code to the Doom video game (prboom) that twobob ported to the K5, with a goal to make it work on all the eink kindles. But when the Paperwhite comes, we REALLY need to learn how to get it into USB Downloader mode, because the new firmware will undoubtedly lead to Paperwhites gathering dust after they get bricked...

[bhaak]

Originally Posted by ixtab

What makes you think that? Has development for the K3 stopped because there are K4 and K5 models out there?

No, but the KT has only been produced for a year and outside the US even been available officially only for ~6 months. There have probably been relatively few units sold compared to K3 models. New US developers won't come to the KT and soon the KP will be available to the rest of the world.

Originally Posted by ixtab

I personally will certainly shift focus in the beginning, because I want to get my own stuff running on the PW. But ideally, things will work both on the K5 and the PW. Depending on how different the firmwares really are, this may result in more or less effort.

Yes, that's exactly the point. How much effort will it be to support both devices? We just don't know yet for sure.

For native applications, it's quite likely that there will be no issues on the level of the CPU. Compiled code per se will likely run on both KT and the KP. But what about dynamically linked libraries? This will depend on how similar their firmware is. Then there are different screen resolutions which might or might not screw up your layout.

I think it would be surprising if wafs and kindlets wouldn't work on both devices. After all, browsers apps and Java apps easily work cross-platform and Amazon deliberately breaking compatibility would be strange. Unfortunately that doesn't include patches to the inner workings of the framework like JBPatch.

Originally Posted by ixtab

Maybe (speculation!) it's even possible to run the 5.2.0 firmware on the K5 - or maybe not. We'll see.

This would of course be the best option for continued KT support.

[eureka]

Originally Posted by bhaak

Yes, that's exactly the point. How much effort will it be to support both devices? We just don't know yet for sure.

For native applications, it's quite likely that there will be no issues on the level of the CPU. Compiled code per se will likely run on both KT and the KP. But what about dynamically linked libraries? This will depend on how similar their firmware is. Then there are different screen resolutions which might or might not screw up your layout.

I think it would be surprising if wafs and kindlets wouldn't work on both devices. After all, browsers apps and Java apps easily work cross-platform and Amazon deliberately breaking compatibility would be strange. Unfortunately that doesn't include patches to the inner workings of the framework like JBPatch.

Different DPI and capacitive touchscreen are already supported by current KT's firmware (and was introduced with 5.1.0 or even earlier). And screenlight is also supported beginning from 5.1.0 (as had been found by ixtab).

It's just reasonable to expect that 5.2.0 is updated 5.1.2, KT-specific code (167 DPI, Neonode zForce touchscreen) wasn't removed and choice between KT- and KP-specific code is made in runtime.

[twobob]

^this. I thought exactly this.

5.1.2++ (read: new label)

[pirl8]

Originally Posted by ixtab

So, I just learned this from here:

This is pretty much what I expected. Although there seem to be some serious UI changes wrt 5.1.0, it's still just an evolution of the "old" K5 firmware, not a complete revolution.

Maybe it's an "involution"? Half the memory, no audio support, no "home" button, 16 instead of 256 levels of grey...

Any clue if the new 5.2.0 firmware already comes with multilanguage support?

[twobob]

and of course 16 colors will nerf the OOTB SDL support IIRC. nice one.

[geekmaster]

Originally Posted by pirl8

Maybe it's an "involution"? Half the memory, no audio support, no "home" button, 16 instead of 256 levels of grey...

Any clue if the new 5.2.0 firmware already comes with multilanguage support?

No eink screens are 256 colors. The K4 and K5 have two copies of the 4-bit value in each byte of the framebuffer. You can verify that by copying a screensaver image to your host PC and run a histogram on it, which will show 16 evenly-spaced spikes (4bpp). And the GPL source code for the eink driver says the top and bottom half of the bytes must match to prevent unpredictable hardware-dependent visual anomalies. Look at my newtrix demo to see how to display 256 colors by dithering it down to 16 colors. There is hardware dithering support in the K4/K5 SoC, but the Kindles don't use it (yet), as it looked when I studied it back in December.

[knc1]

The fewer gray-scale steps would give them better edge definition in the fonts.
And since they are promoting the "sharp and clear" characteristics, it seems a reasonable thing to do from a marketing stand-point.

It would not make as much sense if it was intended as a graphic display device rather than as a book display device.

[geekmaster]

Originally Posted by knc1

The fewer gray-scale steps would give them better edge definition in the fonts.
And since they are promoting the "sharp and clear" characteristics, it seems a reasonable thing to do from a marketing stand-point.

It would not make as much sense if it was intended as a graphic display device rather than as a book display device.

Not fewer. Just not two copies. I posted a thread some time ago, comparing screenshots to screen photos demonstrating the anomalies from not duplicating the top and bottom half-bytes, which was later confirmed in the GPL source code. See my post above for more details.

[knc1]

Originally Posted by geekmaster

Not fewer. Just not two copies. I posted a thread some time ago, comparing screenshots to screen photos demonstrating the anomalies from not duplicating the top and bottom half-bytes, which was later confirmed in the GPL source code. See my post above for more details.

The principle remains, independent of your prior work.

[ixtab]

Originally Posted by pirl8

Any clue if the new 5.2.0 firmware already comes with multilanguage support?

Yes. All the languages of 5.1.2, plus japanese.

[geekmaster]

Originally Posted by knc1

The principle remains, independent of your prior work.

The principle that 16 colors gives better font antialiasing than 256 colors is not necessarily valid, and regarding eink displays, the comparison between 16 and 256 is not valid either. Even an 8-bit framebuffer is only 16 colors. But I think their antialiasing gamma is for LCD panels, when they should be using eink gamma similar to ink on paper.