-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No use of Regal waveform on Kobo Aura #741
Comments
Nope, because no-one with an Aura has dug into how the stock reader actually handles it (and the kernel headers are way less helpful than the Kindle ones). The groundwork should be here though, since I took care of that when I implemented it for the PW2. We just need someone with an Aura to sniff the ioctls (cf. #550 as a point of reference). |
Thanks for the information! |
As I understand it Coolreader uses Waveform on Aura, so someone found out what was necessary... |
@WS64: Which port? (And, more importantly: where are the sources?) Also, to use the proper terminology, I meant regal/reagl waveform handling. We're of course always relying on a waveform update mode of some kind to do stuff with an eInk screen ;). OT: Pet peeve of mine with some of what's out there for the Kobo on MR: where the hell are the sources??! |
I think WS64 is referring to Coolreader from Sergey Vlasov. You can find the sources here: In Germany the regal waveform technology is often simply called waveform, but you are right, the proper terminology is regal waveform. :) |
@trekk2810: "src": This folder is empty w00t. -_-". |
Apologies! I haven't looked in to the folder, just saw src and assumed the sources were in there. I was sure, Sergey made the sources public ... |
If I remembered correctly, Sergey only released the source code of crengine(GPLv2) some place. And you cannot build the CoolReader for Kobo from that source of course because most platform-related code like reading battery information and updating eink screen are closed source. To be honest, I reverse-engineered the binaries to find the battery info file path for Kobo devices. I would say thanks to Sergey. |
Closing this now as of no progress. |
Too bad for us users... Are you sure you don’t want to leave it open until someone comes along that wants to fix it? |
It seems as the issues in the list pile higher people will less likely check through the list and the issues will pile even higher. So if there is no activity on an issue it probably indicates that it's not important or not many people care about it and it should be closed. So if users really want an issue being fixed, they shall at least keep it from being rotten just like you did. :) |
The problem that I for instance have no idea how to help here, although I even own the device in question. |
You'd 'simply' need to trace the few relevant ioctl. I mentioned a few different tools in #550, the cleaner (and easier to use) of which would probably be a proper patch to strace. I'd hoped to have time to actually do it just for kicks for the Kindle (since I in the end did not actually need to resort to such things on the Kindle), but life happened and messed that neat planning up ;). Barring that, the other stuff that involve intercepting & dumping the ioctl might be quicker to whip up. |
Hmm, ltrace might be easier to config to properly grok the relevant ioctls, I'll check it out. |
Meh, no go with ltrace, it segfaults when tracing some stuff (most notably the Kindle WM). Plus, the attached process hangs or crashes in interesting ways, so, noooope. |
Well, if anyone can tell me what to do I will give it a try. |
OK, here's the trace on Kobo Aura. nickel, full update:
nickel, partial update:
(Interestingly, instead of doing MXCFB_WAIT_FOR_UPDATE_COMPLETE right away after the update, nickel does it later, just before the next update.) koreader, full update:
koreader, partial update:
Basically, "Regal waveform" is update_mode=1, waveform_mode=7, flags=4096 (EPDC_FLAG_USE_AAD), followed by MXCFB_WAIT_FOR_UPDATE_COMPLETE. Can't wait to see it in nightly builds. :) |
Strace patch: https://gist.github.com/erosennin/593de363a4361411cd4f |
@erosennin: Many thanks! I don't have a Kobo device, but it should be fairly simple to plug in, I'll try to do that tomorrow if nobody beats me to it ;). Yeah, the MXCFB_WAIT_FOR_UPDATE_COMPLETE behaviour is similar to what's done on the Kindle, the 'doing it just after the send' was also my own interpretation of the thing for KOReader (in the PW2 codepath) ;). EDIT: Scratch that, I was thinking of MXCFB_WAIT_FOR_UPDATE_SUBMISSION, which doesn't actually exists in the Kobo driver. (That said, the PW2 does use MXCFB_WAIT_FOR_UPDATE_COMPLETE in a seemingly unintuitive way, although I'm not completely clear on the details anymore, I'll take a look at it again with a shiny new strace ;p) I will definitely adapt your patch for my Kindle strace builds, so thanks for that also ;). |
Oh, right. I do need a way to differentiate between devices than can do REAGL (Aura & H20, If memory serves?), and those that can't. On the Kindle, I'm using fb.finfo.smem_len, but accordig to comments, that might not be a great idea on Kobos... Not sure if there are any tools bundled on the Kobos that can easily dump that info (besides littering KOReader's ffi/framebuffer_linux.lua with printfs ;p), so I'll be updating my FBGrab build for that... |
You can do a simple check against Device:getModel(), I think. There's a lingering PR of mine that will ease creating device-soecific behaviour. Please don't get too fancy before it's in :-) |
@hwh: I remember not using Device:getModel() because the check is done in korader-base's ffi/framebuffer_linux.lua and Device is in koreader, so I didn't want to wrap my head around that once I found a cheap workaround (since that's a check done on every refresh call) ;). Would your PR help me on that front? In case I can use Device:getModel(), what are the codenames for the Aura & the H20? |
Oh, you're right. No, it won't help there. However, the refresh is triggered via "screen.lua" in the "koreader" code. It just delegates the call to the FFI implementation. I think I would prefer to have both implementations or a parametrized implementation in the FFI part, and the device distinction in the koreader part, calling the relevant function (or giving a parameter leading to the right behaviour). The FFI function in fact has a waveform/refreshtype parameter, but we're not giving it much love at the moment. |
@erosennin , mind if I add your path to koreader-misc repo? @NiLuJe , codename for AuraHD is dragon. According to 7117235 H2O should be dahlia. Not sure about Aura. |
Note that the AuraHD doesn't handle regal waveforms, just the Aura ;). |
Aura is phoenix |
Thanks for the codenames ;). I'll see how I can tweak the flow to move the tests to KOreader, in which case I'll wait for hwhw's refactor to make it to the main tree before sending a PR, but I'll probably try some stuff in a branch on my tree, so I'll keep you updated if I need someone with a Kobo to test something ;). EDIT: Ha, hwhw's PR landed, so, that's that taken care of ;p. |
Yep, the PW2 uses WAIT_FOR_UPDATE_COMPLETE in the same way.
First page turn with a black flash (on text, no pictures), second without. I imagine the partial updates are for the status bar at the bottom of the screen (although in this instance I'm showing nothing there). WAIT_FOR_UPDATE_SUBMISSION is only used when popping up part of the UI with partial updates, for whatever reason... |
Okay, pushed something to my branches (koreader-base & koreader). You only need ffi/framebuffer_linux.lua from koreader-base and frontend/ui/uimanager.lua from koreader to test the changes. For now, I haven't touched the signature of refresh(), so there's a missing test (which leads to basically enforcing the wait-for-previous-update on ALL Kobo devices, which will probably make fast page swiping an annoying experience on older Kobos). I'm open to suggestions on how to best approach this. (Basically, I need to move the fb.wait_for_every_update & fb.wait_for_full_updates checks [which could probably be folded in a single flag, since they're mutually exclusive] from ffi/framebuffer_linux.lua to somewhere relevant in koreader. I'm thinking in UIManager:init() with the rest of the waveform selection logic, but that would probably entail adding a parameter to refresh(), for something that's only used on eInk devices.) The Kobo codepath is obviously completely dry-coded, but I did run a quick check on my PW2 & Touch without anything blowing up ;p (Because I cleaned some stuff up with the data gained from the strace patch, even in the Kindle codepath ^^).
On a related note, I updated my USBNetwork snapshots w/ the new fbgrab & strace builds. (The patches are in the x-tc tarball at the bottom of the first post). I'll get back to this on Friday, so you have some time to play with it ;p. |
Great, it's mostly working! There is a small typo in ffi/framebuffer_linux.lua:60:
After I've changed MXCFB_WAIT_FOR_UPDATE_COMPLETE_PEARL to MXCFB_WAIT_FOR_UPDATE_COMPLETE everything worked as expected. Also, the viewport is slightly off now, but that seems to be unrelated. I'll file a separete issue later. |
@erosennin : Whoops, nice catch, I'll try to fix that in a way that doesn't break the Kindle's side of things ;p. EDIT: Done. |
Fixed the handling of regional updates, which were, in my previous changes, hijacked as FULL REAGL updates, when they probably should have been kept as PARTIAL insert default waveform mode here ;). Dry-coded, I'll check it tomorrow (since I don't even know which kind of UI elements trigger such regional updates in KOReader ;p). |
Yes, it's much better now. It can be easily seen while typing, for example. Those full REAGL updates used to cause noticeable flicker on the text area, and good old partial updates look much better in this case. Also, waiting every update makes menus and keyboard SLOW LIKE HELL. :) There are at least 2 updates for each keypress on the virtual keyboard and 3 updates when switching tabs in the bottom menu. In fact, nickel does not wait for updates at all when typing. That's how it looks:
And it only waits for updates of some chosen regions when switching menus:
Perhaps we should use REAGL updates only for page flipping for now and stick to the old behavior for all the rest? |
Ah, yeah, good idea, I'll see what can do... ;). |
Okay, pushed some new stuff, it should mostly be done, I'm just waiting on a confirmation for the KT2 handling, and then I'll send a PR :). |
Landed in master ;). Ping me if you see something wonky ;). |
Working fine, thanks! |
The 6-inch Aura uses the waveform technology for screen refresh. When I use koreader on this device I set
DRCOUNTMAX = 6
in default.persistent.lua, so I have a full screen refresh every 6 pages. Flipping from page 2 to 5 the screen should use the waveform technology, but it seems that koreader does not use this functionality with Kobo devices?The text was updated successfully, but these errors were encountered: