KPV: a PDF reader for Kindle, based on muPDF, GPLv3

[geekmaster]

Originally Posted by eureka

BTW, upto 5.1.0 (not including 5.1.0), KT had slightly different screen update structure:

• old structure
• discovering of structure change

ioctl command value for updating also was different, I believe: 0x4040462e (or, at least, it's so in geekmaster's video player).

I don't think there are still owners of pre-5.1.0 devices, so it's just an interesting fact. But if you want to differentiate pre-5.1.0 devices: firmware version could be read from /etc/prettyversion.txt on device.

P.S. Oh, I see this "old" structure is already present in include/mxcfb.h as mxcfb_update_data.

I copied the relevant portions of eink_fb.h (for K3 support) and multiple versions of mxc_fb.h (5.0.x and 5.1.x) into my code. You cannot include all files, because they define DIFFERENT incompatible versions of the SAME ioctl structure name...

By copying parts of both includes and including neither of them, my code was able to support for 5.0.x and 5.1.x ioctl calls (and also K3, and K4 main and diags).

More details can be seen at the "discovering" link provided by eureka above.

I also made my code fall back to an eips call if the ioctl() calls fail, just in case the eink ioctl structures change again in some future firmware version. It adds a little robustness to the program, to postpone bit-rot awhile longer...

[eureka]

Originally Posted by eureka

ioctl command value for updating also was different, I believe: 0x4040462e (or, at least, it's so in geekmaster's video player).

This value 0x4040462e is perfectly fit to value of macro MXCFB_SEND_UPDATE, defined in include/mxcfb.h. It's not the discovery, but now I know why ioctl value was changed in 5.1.0: just because of changed update structure size.

I suggest to update include/mxcfb.h with the following addition (belonged to public domain):

// Starting from firmware version 5.1.0, framebuffer update structure
// (actual for Kindle Touch and then Kindle Paperwhite) was changed
// and so appropriate update ioctl value.
#define MXCFB_SEND_UPDATE51 _IOW('F', 0x2E, struct mxcfb_update_data51)

Then just use MXCFB_SEND_UPDATE51 instead of raw value 0x4048462e in function kindlePWeinkUpdate().

(Related macros -- _IOW etc. -- could be found in include/asm-generic/ioctl.h from Kindle kernel source, or online. Two new __u32 members of update structure, i.e. 8 bytes, lead to change of 40 to 48).

UPD: OK, now I understand why you are using raw value -- to avoid dependency on that ioctl.h from kernel source. Still, it would be useful at least add comment about how this raw value was calculated.

[bhaak]

Originally Posted by dave2008

Aha, that makes sense now. I previously thought mxcfb_update_data is for KT, so I was somehow suprised to see kindlePWeinkUpdate works in your KT.

I probably won't support version before 5.1.0 for now, until any pre-5.1.0 user come here and complain ;p

I don't think it makes sense to support pre-5.1.0 KTs. To my knowledge there is no reason not to upgrade to 5.1.0+ and from a coding perspective all 5.1.x firmwares should be practically the same.

[dave2008]

Originally Posted by geekmaster

I copied the relevant portions of eink_fb.h (for K3 support) and multiple versions of mxc_fb.h (5.0.x and 5.1.x) into my code. You cannot include all files, because they define DIFFERENT incompatible versions of the SAME ioctl structure name...

By copying parts of both includes and including neither of them, my code was able to support for 5.0.x and 5.1.x ioctl calls (and also K3, and K4 main and diags).

Yes, that's what I did. Actually my code was adapted from your video player. Baiscally, when I want to know how to communicate with kindle in low-level, I will first look for your code and I can always find what I want

Originally Posted by eureka

TOK, now I understand why you are using raw value -- to avoid dependency on that ioctl.h from kernel source. Still, it would be useful at least add comment about how this raw value was calculated.

In fact, the reason why I use raw value is I don't know it can be constructed in that way ;P Now I know it, thanks. I tried your patch and it compiles without any error even though ioctl.h is not included (at least I cannot find it in the build environment). That's strange...

But the real problem is the actual size of mxcfb_update_data51 is 0x4c here, not 0x48 (mxcfb_update_data is also 4 bytes larger). I double checked the definition of the structure, it is the same as the one in geekmaster's video player. Any thought?

Originally Posted by bhaak

I don't think it makes sense to support pre-5.1.0 KTs. To my knowledge there is no reason not to upgrade to 5.1.0+ and from a coding perspective all 5.1.x firmwares should be practically the same.

thanks, so HUR also only supports 5.1 firmware?

[knc1]

Compiler version and/or flags affecting structure member alignment.

[dave2008]

Originally Posted by knc1

Compiler version and/or flags affecting structure member alignment.

I tried to calculate the size by hand, seems that the miminal size is 0x4c. Could it be Compiler version and/or flags affecting size of the members?

[knc1]

Originally Posted by dave2008

I tried to calculate the size by hand, seems that the miminal size is 0x4c. Could it be Compiler version and/or flags affecting size of the members?

Yes.
Read the release notes and bug reports for arm on that compiler version.

(If you built it yourself, you may have to write those notes. )

[eureka]

Originally Posted by dave2008

In fact, the reason why I use raw value is I don't know it can be constructed in that way ;P Now I know it, thanks. I tried your patch and it compiles without any error even though ioctl.h is not included (at least I cannot find it in the build environment). That's strange...

There is #include <sys/ioctl.h> in einkfb.c, so host system ioctl.h is used in compilation. Full chain is sys/ioctl.h -> bits/ioctl-types.h -> asm/ioctls.h -> asm-generic/ioctls.h -> linux/ioctl.h -> asm/ioctl.h -> asm-generic/ioctl.h -> _IOW found. Don't know, whether it's OK or bad (to use host system ioctl.h header)...

Originally Posted by dave2008

But the real problem is the actual size of mxcfb_update_data51 is 0x4c here, not 0x48 (mxcfb_update_data is also 4 bytes larger). I double checked the definition of the structure, it is the same as the one in geekmaster's video player. Any thought?

Ha-ha, really size is 0x4c. I didn't even try to calculate real size, just checked that other components are exactly the same.

It means, one 4-byte field is superfluous.

Here is definition of mxcfb_alt_buffer_data from include/linux/mxcfb.h from 5.3.0 kernel source:

struct mxcfb_alt_buffer_data {
  __u32 phys_addr;
  __u32 width;  /* width of entire buffer */
  __u32 height;  /* height of entire buffer */
  struct mxcfb_rect alt_update_region;  /* region within buffer to update */
};

UPD: I also think that it's better to rename mxcfb_update_data51 to mxcfb_update_data and current mxcfb_update_data to mxcfb_update_data_50x (or to something like this) and add comment to mxcfb_update_data_50x (about it's validity only in 5.0.x firmwares). And add MXCFB_SEND_UPDATE_50X for usage with mxcfb_update_data_data_50x. Reason: KPV doesn't have legacy of supporting 5.0.x and, probably, will never have, so suffix 51 is excessive.

[dave2008]

Thanks @eureka and @knc1, the eink module is done

I will handle the touch coordinates now. It's wierd that it generates ranges from 0 to 4095

[dave2008]

Ok, touch coordinates are handled now. Let me know if it works or not

[eureka]

Originally Posted by dave2008

Ok, touch coordinates are handled now. Let me know if it works or not

Works fine with the small patch:

diff --git a/frontend/ui/inputevent.lua b/frontend/ui/inputevent.lua
index daa21ec..4c5712d 100644
--- a/frontend/ui/inputevent.lua
+++ b/frontend/ui/inputevent.lua
@@ -272,11 +272,12 @@ function Input:init()
                                        --@TODO handle coordinates properly after
                                        --screen rotate.    (houqp)
                                        if ev.code == ABS_MT_POSITION_X then
-                                               ev.code = math.round(ev.code * (600/4095))
+                                               ev.value = math.round(ev.value * (600/4095))
                                        elseif ev.code == ABS_MT_POSITION_Y then
-                                               ev.code = math.round(ev.code * (800/4095))
+                                               ev.value = math.round(ev.value * (800/4095))
                                        end
                                end
+                               return ev
                        end
                        print("Auto-detected Kindle Touch")
                elseif dev_mod == "Kindle4" then

E Ink module is also works filne on KT now.

[dave2008]

Cant believe I made such a stupid mistake...

Anyway, thanks a lot! Finally full kindle devices support

[bhaak]

Originally Posted by dave2008

thanks, so HUR also only supports 5.1 firmware?

HUR should also support 5.0.x but just because there were no high level changes in the firmware that would have made it incompatible with the older firmwares.

IIRC not even the GUI launcher extension in Java needed an update. But the GUI launcher itself did as with 5.1.0 the Java obfuscator was used more aggressively again.

If there were issues I would have supported 2 different version only if it were feasible. Sometimes it's just not possible without much work to support different versions and Amazon doesn't make it easier with all the hurdles they've built.

Also, let's face it, the KT was on the market for such a short time that the number of people with 5.0.x firmware is already negligible compared to the KPW numbers and maybe even the KT itself will be too if Amazon doesn't give out a 5.3.x firmware for it (what they easily could do as the hardware is almost identical besides the larger screen and the missing home button).

[thomass]

Originally Posted by aranwe

... i don't have working cross-compiling setup and i would really like to try this

see this post
(I also don't know and will try )

[twobob]

lua config error: ./rendertext.lua:30: attempt to index local 'face' (a nil value)

think somehow my fonts it dont like? err or something? - nightly build, but the previous one had same error.