Skip to content
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

Closed
trekk2810 opened this issue Jul 20, 2014 · 37 comments
Closed

No use of Regal waveform on Kobo Aura #741

trekk2810 opened this issue Jul 20, 2014 · 37 comments
Labels

Comments

@trekk2810
Copy link

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?

@NiLuJe
Copy link
Member

NiLuJe commented Jul 20, 2014

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).

@trekk2810
Copy link
Author

Thanks for the information!

@WS64
Copy link
Contributor

WS64 commented Jul 20, 2014

As I understand it Coolreader uses Waveform on Aura, so someone found out what was necessary...

@NiLuJe
Copy link
Member

NiLuJe commented Jul 20, 2014

@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??!

@trekk2810
Copy link
Author

I think WS64 is referring to Coolreader from Sergey Vlasov. You can find the sources here:
https://www.dropbox.com/sh/9xqopxa4yvg9n3i/VrYWEBVJUB/builds

In Germany the regal waveform technology is often simply called waveform, but you are right, the proper terminology is regal waveform. :)

@NiLuJe
Copy link
Member

NiLuJe commented Jul 21, 2014

@trekk2810: "src": This folder is empty

w00t. -_-".

@trekk2810
Copy link
Author

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 ...

@chrox
Copy link
Member

chrox commented Aug 12, 2014

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.

@chrox chrox added the Kobo label Aug 14, 2014
@chrox
Copy link
Member

chrox commented Oct 8, 2014

Closing this now as of no progress.

@chrox chrox closed this as completed Oct 8, 2014
@nomeata
Copy link

nomeata commented Oct 8, 2014

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?

@chrox chrox changed the title No use of waveform technology on Kobo Aura? No use of Regal waveform on Kobo Aura Oct 8, 2014
@chrox
Copy link
Member

chrox commented Oct 8, 2014

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. :)

@chrox chrox reopened this Oct 8, 2014
@WS64
Copy link
Contributor

WS64 commented Oct 8, 2014

The problem that I for instance have no idea how to help here, although I even own the device in question.

@NiLuJe
Copy link
Member

NiLuJe commented Oct 8, 2014

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.

@NiLuJe
Copy link
Member

NiLuJe commented Oct 8, 2014

Hmm, ltrace might be easier to config to properly grok the relevant ioctls, I'll check it out.

@NiLuJe
Copy link
Member

NiLuJe commented Oct 8, 2014

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.

@WS64
Copy link
Contributor

WS64 commented Oct 8, 2014

Well, if anyone can tell me what to do I will give it a try.

@erosennin
Copy link
Contributor

OK, here's the trace on Kobo Aura.

nickel, full update:

ioctl(3, MXCFB_WAIT_FOR_UPDATE_COMPLETE, {20}) = 0
ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=0, left=0, width=758, height=1024}, waveform_mode=2, update_mode=1, update_marker=21, temp=4096, flags=0}) = 0

nickel, partial update:

ioctl(3, MXCFB_WAIT_FOR_UPDATE_COMPLETE, {21}) = 0
ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=0, left=0, width=758, height=1024}, waveform_mode=7, update_mode=1, update_marker=22, temp=4096, flags=4096}) = 0

(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:

ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=0, left=0, width=1024, height=758}, waveform_mode=2, update_mode=1, update_marker=12, temp=4096, flags=0}) = 0

koreader, partial update:

ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=0, left=0, width=1024, height=758}, waveform_mode=2, update_mode=0, update_marker=13, temp=4096, flags=0}) = 0

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. :)

@erosennin
Copy link
Contributor

@NiLuJe
Copy link
Member

NiLuJe commented Nov 4, 2014

@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 ;).

@NiLuJe
Copy link
Member

NiLuJe commented Nov 4, 2014

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...

@hwhw
Copy link
Member

hwhw commented Nov 4, 2014

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 :-)

@NiLuJe
Copy link
Member

NiLuJe commented Nov 4, 2014

@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?

@hwhw
Copy link
Member

hwhw commented Nov 4, 2014

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.

@houqp
Copy link
Member

houqp commented Nov 5, 2014

@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.

@NiLuJe
Copy link
Member

NiLuJe commented Nov 5, 2014

Note that the AuraHD doesn't handle regal waveforms, just the Aura ;).

@WS64
Copy link
Contributor

WS64 commented Nov 5, 2014

Aura is phoenix

@NiLuJe
Copy link
Member

NiLuJe commented Nov 5, 2014

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.

@NiLuJe
Copy link
Member

NiLuJe commented Nov 5, 2014

Yep, the PW2 uses WAIT_FOR_UPDATE_COMPLETE in the same way.

[pid  3306] 16:34:48 [40644d4c] ioctl(18, MXCFB_WAIT_FOR_UPDATE_COMPLETE, {update_marker=4739, collision_test=1084179424}) = 0
[pid  3306] 16:34:48 [40644d4c] ioctl(18, MXCFB_SEND_UPDATE, {update_region={top=0, left=0, width=758, height=1024}, waveform_mode=WAVEFORM_MODE_GC16_FAST, update_mode=UPDATE_MODE_FULL, update_marker=4740, hist_bw_waveform_mode=WAVEFORM_MODE_DU, hist_gray_waveform_mode=WAVEFORM_MODE_GC16_FAST, temp=TEMP_USE_AUTO, flags=0, alt_buffer_data={phys_addr=0, width=0, height=0, alt_update_region={top=0, left=0, width=0, height=0}}}) = 0
[pid  3306] 16:34:48 [40644d4c] ioctl(18, MXCFB_WAIT_FOR_UPDATE_COMPLETE, {update_marker=4740, collision_test=1}) = 442
[pid  3306] 16:34:48 [40644d4c] ioctl(18, MXCFB_SEND_UPDATE, {update_region={top=1004, left=0, width=758, height=20}, waveform_mode=WAVEFORM_MODE_AUTO, update_mode=UPDATE_MODE_PARTIAL, update_marker=4741, hist_bw_waveform_mode=WAVEFORM_MODE_DU, hist_gray_waveform_mode=WAVEFORM_MODE_GC16_FAST, temp=TEMP_USE_AUTO, flags=0, alt_buffer_data={phys_addr=0, width=0, height=0, alt_update_region={top=0, left=0, width=0, height=0}}}) = 0
[pid  3306] 16:34:53 [40644d4c] ioctl(18, MXCFB_WAIT_FOR_UPDATE_COMPLETE, {update_marker=4741, collision_test=1084179424}) = 0
[pid  3306] 16:34:53 [40644d4c] ioctl(18, MXCFB_SEND_UPDATE, {update_region={top=0, left=0, width=758, height=1024}, waveform_mode=WAVEFORM_MODE_REAGL, update_mode=UPDATE_MODE_FULL, update_marker=4742, hist_bw_waveform_mode=WAVEFORM_MODE_REAGL, hist_gray_waveform_mode=WAVEFORM_MODE_REAGL, temp=TEMP_USE_AUTO, flags=0, alt_buffer_data={phys_addr=0, width=0, height=0, alt_update_region={top=0, left=0, width=0, height=0}}}) = 0
[pid  3306] 16:34:53 [40644d4c] ioctl(18, MXCFB_WAIT_FOR_UPDATE_COMPLETE, {update_marker=4742, collision_test=4}) = 442
[pid  3306] 16:34:54 [40644d4c] ioctl(18, MXCFB_SEND_UPDATE, {update_region={top=1004, left=0, width=758, height=20}, waveform_mode=WAVEFORM_MODE_AUTO, update_mode=UPDATE_MODE_PARTIAL, update_marker=4743, hist_bw_waveform_mode=WAVEFORM_MODE_DU, hist_gray_waveform_mode=WAVEFORM_MODE_GC16_FAST, temp=TEMP_USE_AUTO, flags=0, alt_buffer_data={phys_addr=0, width=0, height=0, alt_update_region={top=0, left=0, width=0, height=0}}}) = 0

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...

@NiLuJe
Copy link
Member

NiLuJe commented Nov 5, 2014

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 ^^).

[pid  5549] 21:50:21 [40316d4c] ioctl(3, MXCFB_WAIT_FOR_UPDATE_COMPLETE, {update_marker=13, collision_test=0}) = 0
[pid  5549] 21:50:21 [40316d4c] ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=0, left=0, width=758, height=1024}, waveform_mode=WAVEFORM_MODE_GC16, update_mode=UPDATE_MODE_FULL, update_marker=14, hist_bw_waveform_mode=WAVEFORM_MODE_DU, hist_gray_waveform_mode=WAVEFORM_MODE_GC16, temp=TEMP_USE_AUTO, flags=0, alt_buffer_data={phys_addr=0, width=0, height=0, alt_update_region={top=0, left=0, width=0, height=0}}}) = 0
[pid  5549] 21:50:21 [40316d4c] ioctl(3, MXCFB_WAIT_FOR_UPDATE_SUBMISSION, {14}) = 499
[pid  5549] 21:50:23 [40316d4c] ioctl(3, MXCFB_WAIT_FOR_UPDATE_COMPLETE, {update_marker=14, collision_test=0}) = 0
[pid  5549] 21:50:23 [40316d4c] ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=0, left=0, width=758, height=1024}, waveform_mode=WAVEFORM_MODE_REAGL, update_mode=UPDATE_MODE_FULL, update_marker=15, hist_bw_waveform_mode=WAVEFORM_MODE_REAGL, hist_gray_waveform_mode=WAVEFORM_MODE_REAGL, temp=TEMP_USE_AUTO, flags=0, alt_buffer_data={phys_addr=0, width=0, height=0, alt_update_region={top=0, left=0, width=0, height=0}}}) = 0
[pid  5549] 21:50:23 [40316d4c] ioctl(3, MXCFB_WAIT_FOR_UPDATE_SUBMISSION, {15}) = 497
[pid  5549] 21:50:23 [40316d4c] ioctl(3, MXCFB_WAIT_FOR_UPDATE_COMPLETE, {update_marker=15, collision_test=0}) = 0
[pid  5549] 21:50:23 [40316d4c] ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=0, left=0, width=758, height=1024}, waveform_mode=WAVEFORM_MODE_REAGL, update_mode=UPDATE_MODE_FULL, update_marker=16, hist_bw_waveform_mode=WAVEFORM_MODE_REAGL, hist_gray_waveform_mode=WAVEFORM_MODE_REAGL, temp=TEMP_USE_AUTO, flags=0, alt_buffer_data={phys_addr=0, width=0, height=0, alt_update_region={top=0, left=0, width=0, height=0}}}) = 0
[pid  5549] 21:50:23 [40316d4c] ioctl(3, MXCFB_WAIT_FOR_UPDATE_SUBMISSION, {16}) = 497
[pid  5549] 21:50:24 [40316d4c] ioctl(3, MXCFB_WAIT_FOR_UPDATE_COMPLETE, {update_marker=16, collision_test=0}) = 0
[pid  5549] 21:50:24 [40316d4c] ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=0, left=0, width=758, height=1024}, waveform_mode=WAVEFORM_MODE_REAGL, update_mode=UPDATE_MODE_FULL, update_marker=1, hist_bw_waveform_mode=WAVEFORM_MODE_REAGL, hist_gray_waveform_mode=WAVEFORM_MODE_REAGL, temp=TEMP_USE_AUTO, flags=0, alt_buffer_data={phys_addr=0, width=0, height=0, alt_update_region={top=0, left=0, width=0, height=0}}}) = 0
[pid  5549] 21:50:24 [40316d4c] ioctl(3, MXCFB_WAIT_FOR_UPDATE_SUBMISSION, {1}) = 497
[pid  5549] 21:50:25 [40316d4c] ioctl(3, MXCFB_WAIT_FOR_UPDATE_COMPLETE, {update_marker=1, collision_test=0}) = 0
[pid  5549] 21:50:25 [40316d4c] ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=0, left=0, width=758, height=1024}, waveform_mode=WAVEFORM_MODE_REAGL, update_mode=UPDATE_MODE_FULL, update_marker=2, hist_bw_waveform_mode=WAVEFORM_MODE_REAGL, hist_gray_waveform_mode=WAVEFORM_MODE_REAGL, temp=TEMP_USE_AUTO, flags=0, alt_buffer_data={phys_addr=0, width=0, height=0, alt_update_region={top=0, left=0, width=0, height=0}}}) = 0
[pid  5549] 21:50:25 [40316d4c] ioctl(3, MXCFB_WAIT_FOR_UPDATE_SUBMISSION, {2}) = 497
[pid  5549] 21:50:26 [40316d4c] ioctl(3, MXCFB_WAIT_FOR_UPDATE_COMPLETE, {update_marker=2, collision_test=0}) = 0
[pid  5549] 21:50:26 [40316d4c] ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=0, left=0, width=758, height=1024}, waveform_mode=WAVEFORM_MODE_REAGL, update_mode=UPDATE_MODE_FULL, update_marker=3, hist_bw_waveform_mode=WAVEFORM_MODE_REAGL, hist_gray_waveform_mode=WAVEFORM_MODE_REAGL, temp=TEMP_USE_AUTO, flags=0, alt_buffer_data={phys_addr=0, width=0, height=0, alt_update_region={top=0, left=0, width=0, height=0}}}) = 0
[pid  5549] 21:50:26 [40316d4c] ioctl(3, MXCFB_WAIT_FOR_UPDATE_SUBMISSION, {3}) = 497
[pid  5549] 21:50:27 [40316d4c] ioctl(3, MXCFB_WAIT_FOR_UPDATE_COMPLETE, {update_marker=3, collision_test=0}) = 0
[pid  5549] 21:50:27 [40316d4c] ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=0, left=0, width=758, height=1024}, waveform_mode=WAVEFORM_MODE_GC16, update_mode=UPDATE_MODE_FULL, update_marker=4, hist_bw_waveform_mode=WAVEFORM_MODE_DU, hist_gray_waveform_mode=WAVEFORM_MODE_GC16, temp=TEMP_USE_AUTO, flags=0, alt_buffer_data={phys_addr=0, width=0, height=0, alt_update_region={top=0, left=0, width=0, height=0}}}) = 0
[pid  5549] 21:50:27 [40316d4c] ioctl(3, MXCFB_WAIT_FOR_UPDATE_SUBMISSION, {4}) = 500

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.

@erosennin
Copy link
Contributor

Great, it's mostly working!

There is a small typo in ffi/framebuffer_linux.lua:60:

./luajit: ffi/framebuffer_linux.lua:60: missing declaration for symbol 'MXCFB_WAIT_FOR_UPDATE_COMPLETE_PEARL'
stack traceback:
        [C]: in function '__index'
        ffi/framebuffer_linux.lua:60: in function 'einkWaitForCompleteFunc'
        ffi/framebuffer_linux.lua:289: in function 'refresh'
        frontend/device/screen.lua:87: in function 'refresh'
        frontend/ui/uimanager.lua:421: in function 'run'
        ./reader.lua:154: in main chunk
        [C]: at 0x00013859

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.

@NiLuJe
Copy link
Member

NiLuJe commented Nov 6, 2014

@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.

@NiLuJe
Copy link
Member

NiLuJe commented Nov 6, 2014

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).

@erosennin
Copy link
Contributor

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 ;).

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:

ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=668, left=22, width=65, height=65}, waveform_mode=257, update_mode=0, update_marker=404, temp=4096, flags=0x0}) = 0
ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=668, left=22, width=65, height=65}, waveform_mode=257, update_mode=0, update_marker=405, temp=4096, flags=0x0}) = 0
ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=100, left=40, width=678, height=64}, waveform_mode=257, update_mode=0, update_marker=406, temp=4096, flags=0x0}) = 0
ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=668, left=86, width=66, height=65}, waveform_mode=257, update_mode=0, update_marker=407, temp=4096, flags=0x0}) = 0
ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=668, left=86, width=66, height=65}, waveform_mode=257, update_mode=0, update_marker=408, temp=4096, flags=0x0}) = 0
ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=100, left=40, width=678, height=64}, waveform_mode=257, update_mode=0, update_marker=409, temp=4096, flags=0x0}) = 0
ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=668, left=86, width=66, height=65}, waveform_mode=257, update_mode=0, update_marker=410, temp=4096, flags=0x0}) = 0
ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=668, left=86, width=66, height=65}, waveform_mode=257, update_mode=0, update_marker=411, temp=4096, flags=0x0}) = 0
ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=100, left=40, width=678, height=64}, waveform_mode=257, update_mode=0, update_marker=412, temp=4096, flags=0x0}) = 0

And it only waits for updates of some chosen regions when switching menus:

ioctl(3, MXCFB_WAIT_FOR_UPDATE_COMPLETE, {501}) = 0
ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=919, left=332, width=106, height=40}, waveform_mode=257, update_mode=0, update_marker=504, temp=4096, flags=0x0}) = 0
ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=100, left=40, width=678, height=64}, waveform_mode=257, update_mode=0, update_marker=505, temp=4096, flags=0x0}) = 0
ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=641, left=246, width=278, height=278}, waveform_mode=257, update_mode=0, update_marker=506, temp=4096, flags=0x0}) = 0
ioctl(3, MXCFB_WAIT_FOR_UPDATE_COMPLETE, {504}) = 0
ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=919, left=332, width=106, height=40}, waveform_mode=257, update_mode=0, update_marker=507, temp=4096, flags=0x0}) = 0
ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=100, left=40, width=678, height=64}, waveform_mode=257, update_mode=0, update_marker=508, temp=4096, flags=0x0}) = 0
ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=566, left=108, width=278, height=75}, waveform_mode=257, update_mode=0, update_marker=509, temp=4096, flags=0x0}) = 0
ioctl(3, MXCFB_WAIT_FOR_UPDATE_COMPLETE, {506}) = 0
ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=641, left=108, width=416, height=278}, waveform_mode=257, update_mode=0, update_marker=510, temp=4096, flags=0x0}) = 0
ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=919, left=172, width=149, height=40}, waveform_mode=257, update_mode=0, update_marker=511, temp=4096, flags=0x0}) = 0
ioctl(3, MXCFB_WAIT_FOR_UPDATE_COMPLETE, {507}) = 0
ioctl(3, MXCFB_SEND_UPDATE, {update_region={top=919, left=332, width=106, height=40}, waveform_mode=257, update_mode=0, update_marker=512, temp=4096, flags=0x0}) = 0

Perhaps we should use REAGL updates only for page flipping for now and stick to the old behavior for all the rest?

@NiLuJe
Copy link
Member

NiLuJe commented Nov 7, 2014

Ah, yeah, good idea, I'll see what can do... ;).

@NiLuJe
Copy link
Member

NiLuJe commented Nov 8, 2014

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 :).

@NiLuJe
Copy link
Member

NiLuJe commented Nov 8, 2014

Landed in master ;).

Ping me if you see something wonky ;).

@NiLuJe NiLuJe closed this as completed Nov 8, 2014
@erosennin
Copy link
Contributor

Working fine, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants