Missing 'Regal' WaveForm update mode support on Carta E-ink screens (PW2) #550
Comments
|
Just to make sure, the full refresh has the same render effect right? |
|
AFAICT, that's just the usual difference between the Pearl & Carta screens. The PW2 (Carta) ghosts very differently. It does appear to leave a bit more ghosting around, but on the other hand, it does almost no (much more annoying, IMHO) reverse ghosting when said ghosting 'eats' into black text on a new page. As usual, YMMV, because of the usual prod/QA variances of the eInk tech. (And the fact that I personally always had mostly not-that-great Viz/Pearl screens, while the Carta on my PW2 is very good). (I'm talking about the 'no-black-flash' refresh mode here [can't remember the constants that corresponds to for the eInk driver], the situation with full refreshes is totally different (and again, much better on the Carta than Viz/Pearl), and Kobo's weird gray (actually, checkered black) flash on their latest device (Aura?) is another beast entirely). |
|
@NiLuJe , OK, that's interesting. By 'black-flash' refresh mode, you mean full refresh right? @bugportal , do you get the same render result with official reader? |
|
@houqp : Yep! |
|
@NiLuJe , i am just being too lazy to search the web since you are the expert here :P Did Amazon release the driver code for PW2? |
|
They've released the source packages, and the Kernel's in there, but they're notorious for leaving stuff out of those, and I haven't checked how complete the latest source releases were in that regard, sorry ;). |
|
cool, I will take a look at the kernel source when I have time :) |
|
@houqp ： I think the full refresh of Koreder is OK. It do clear all the ghost and leave a brand new page rendering. It appears that for PDF files, the official reader "black-flash" every time when turning to a new page or movement in "zoom in" mode. While for MOBI files, it usually wait around 12 pages to the next "black-flash", although there may be other situations this number varies. The rendering effect of the official reader is great, when compared to the current Koreader on PW2. |
chrox
changed the title
chrox
changed the title
|
FWIW, nothing weird jumped out at me when I checked out KOReader on a PW2 for #519 ;). |
|
So we will close it. |
|
Yep, I mostly think this boils down to how CRe/MuPDF use FT, which I mostly gave up on trying to understand (and make behave like I actually prefer to...). To expand a bit: mostly how fonts are hinted. I can't figure out what CRe does, but it's mostly 'fuzzier' than it should, which makes ghosting worse with no black flash. |
|
Okay, I might have been a bit hasty... We do seem to refresh slower than the stock reader, and that leads to a slightly more pronounced ghosting effect... I'll see if I can dig up something w/ strace, but it's going to take a while, I have to build a strace against the correct kernel to get meaningful stuff... |
|
Ugh. This is with Built against a stock kernel, because I'm lazy and I'm not even sure it'd be that helpful to build against Amazon's anyway. So, KOReader page turns: Stock KF8 reader page turns (by attaching to awesome, fd 18 is indeed /dev/fb0) So, three calls per refresh, they do something more. Yay. I'll check the Kernel just for kicks, but this is mostly way, way over my head, so, good luck :D. If someone wants to go the extra mile, maybe going in with gdb to inspect those addresses might be helpful to decode the struct, but, err, good luck :D. |
|
Yep, there's new stuff in the mxcfb.h header. Among a lot of other things: woot? That 'nearly' matches the 'regal waveform tech' PR spiel. TL;DR: We can probably do better, but this is way over my head. |
|
With a smarter* strace build: KOReader: Awesome: (Homescreen -> Booklet -> Homescreen) *: cf. HACKING-scripts in a git checkout of strace, the ioctlent.sh script did wonders with the 5.4.3.2 kernel ;). |
|
If the headers are not enough, some kobo guys used this at one point to decode the struct. |
|
So, that's it. I can provide the strace build and be an obedient guinea pig, but the rest is over my head ;). |
NiLuJe
changed the title
NiLuJe
changed the title
|
Slightly more accurate title/labels for the issue ;). |
|
Well, digging into old posts by GM can be insightful, more info on the marker thing (which likely saw some changes on the PW2, given the new data structure & ioctl): http://www.mobileread.com/forums/showpost.php?p=2065117&postcount=34 And another tracing tool: http://www.mobileread.com/forums/showpost.php?p=1908766&postcount=4 The FreeScale iMX6 doc might also be useful, but I haven't looked at it. |
|
And for the Kobo guys: OHAI! ;D (Which means mxcfb-kobo.h is also outdated. That's just a heads up, I don't have a Kobo, I was just investigating why we're using the wrong temp value on the Kindle: and that's because it's a Kindle-only one ;)) |
|
Eh, just read a few chapters, might actually be better now. I need new glasses. >_<". |
|
@NiLuJe 👍 Thank you for your help. It looks quite better now. Although I found a problem of the build when I was turning the pages very fast. (It is totally OK when I turned the pages at "normal" speed). Cheers, |
|
Ah, that's probably why the Kindle framework makes sure the last transition is already done (MXCFB_WAIT_FOR_UPDATE_COMPLETE). Seems to be a typical asynchronous interface. |
|
@hwhw: Wild guess here, because I'm fairly certain I don't quite get how everything works, but I'm guessing that's a no-no for us, because we're not multi-process/multi-thread, so a blocking ioctl would be bad? Or does the ioctl return immediately, and the blocking happens elsewhere? @bugportal: Yay, thanks for looking at this, I'm starting to get cross-eyed, wasn't sure it was actually any better ;). I'll update the kobo headers if I have time later tonight, but since I don't have one, I'll leave the actual implementation to someone with an actual device :). The snippet earlier was from the Aura Kernel, but I'm guessing the AuraHD should handle that too. |
|
Both |
|
@NiLuJe Yes, The "unpredictable" rendering will disappear when a full flash is hit, i.e., when I came across the "unpredictable" rendering, just turned the pages at a normal speed, then after some steps, a full flash will make the page clear and rendering back to normal again. I did not change any refresh settings. |
|
@bugportal: Yup, you didn't do anything wrong ;). FWIW, a Touch behaves the exact same way (albeit with a slightly different kind of ghosting). Depending on if you happen to stop right after a full refresh or not, it's more or less readable ;p. |
|
And here's an updated build with my latest PRs baked in. Granted, the two PRs in question haven't much to do with this issue, but, hey :D. I did move the waveform selection code, so do shout at me if I broke it :p. |
|
I think I just kernel panic'ed a PW2. :D. The kernel log buffer is a bit messed up, so no real idea of what crashed, but FWIW, I was clicking the "decrease" contrast button (something that now works just fine after the reboot, so, yay). Good news: the watchdog works really well, ended up rebooting all alone. Probably a good sign it's time to go to sleep! |
|
Okay, I'm doing experiments w/ the WAIT_FOR_STUFF, and I have something that works. I handle everything in fb_linux, because it's easier, and seems saner, and I went with: tweakign refresh() to do: Because that seems like the right way to do it? No idea why the PW2 seems to be doing WAIT_FOR_COMPLETE twice, but there's a kfree() in that function that scares me, so I'm not doing it twice on the same marker :D. The marker is an uint32_t, increasing from 1 to 16 and wrapping. That seems to work, and the 'click next page like a madman' thing indeed behaves more like the Stock reader (in that it, well, waits ;D). The good news is: I forgot to put timestamps around, and I'll probably do it before the end to check, but the blocking appears to be relatively minimal, and the timeout only triggers if you did something wrong ;). I don't handle return values right now, so we just eat a timeout and continue if something wrong happens. Stracing appears to confirm that we're doing something right, I get the same kind of output as the stock reader. I have a couple of issues, though:
So, I guess that boils down to: can I require Device from inside ffi/framebuffer_linux, or do I have to reimplement the device check myself, and essentially duplicate some code? |
|
Pushed to the mxcb_wait_for branch in my tree if someone wants to take a look. |
|
AFAIR, there's nothing in the fb info to tell a PW1 from a PW2. I'll check, but I don't have high hopes ;p. |
|
Good work 👍 ! |
|
@houqp: It's MXCFB_WAIT_FOR_UPDATE_COMPLETE in both cases, but the arg changed on the PW2, so I renamed the onstant for the 'old' ioctl to be able to use both ;). I made that clearer in the header now, thanks :). It appears that I got lucky, and there may be a way to differentiate the PW2 from the fb info. I got sidetracked by the whole gcc-lua/gcc-lua-cdecl stuff (cf. the mess I made in my koreader-misc tree and the latest batch of commits in mxc_wait_for), I'll get back to it now that I tracked down what was broken. (Well, not exactly, but at least it works with the latest versions xD). |
|
Because it might come in handy later, framebuffer info (via eips -i) on the Kindles: Touch (5.3.7.1): PW1 (5.4.4.2): PW2 (5.4.3.2): And for ref., on a Touch w/ FW 5.0, see GM's post here ;). [Meaning we have a way to detect those, so we could support it, if it wasn't fairly useless to do so ^^] |
|
There, the branch should be in a saner state now. More testing tomorrow :). |
|
And this is now KOReader on a PW2: \o/ |
|
The behavior @bugportal encountered is now fixed, as we behave mostly like the stock reader. (Which means, yeah, you can't really tap next page like a crazy person anymore, but you can't do that anymore with the stock reader either on a PW2 ;)). |
|
And here's an updated build with these changes :). |
|
Landed in master, closing ;). (As usual, reopen if stuff suddenly starts catching fire ;)). |
|
And a new build, post merge (so, technically, only the version number should have changed ;)). EDIT: Except I built 352 w/ O3 and 356 w/ the default CFLAGS, which explains the size difference. |
Followup fix to 55fa104: if there's not a single '* {}' or '.cls {}' in a stylesheet, none of it would have been matched and applied.
The rendering effect of Koreader on KPW2 seems different from that of KPW1. In KPW1, the rendering effect is good while in KPW2, 2 or 3 pages partial refresh after one full screen fresh, there remains a lot of e-ink in the screen. As can be seen from the figures attached, in KPW1, the blank region (upper part) is as white as expected, but in KPW2 the blank region (below part) seems contain a lot of "boundary" ink of the characters from previous pages. Such phenomenon is more obvious for the screen regions which is changing from text to images.
One of the developer told me that it may be because the default waveform setting is incorrect. He suggested changing line 26 in frontend/ui/uimanager.lua into:
default_waveform_mode = 8; -- REAGL waveform
However, such change disables the full refresh. Could any developer who owns a KPW2 help to solve this problem?
The text was updated successfully, but these errors were encountered: