Tiny refresh glitch

[snelg]

I don't know enough low-level details to diagnose whether this is a KOReader issue, an rm2fb issue, or some combination of both. KOReader v2021.01 rm2fb v0.0.2

Sometimes KOReader info boxes pop open only half-formed. I can consistently reproduce it with the "Network Info" message, showing here:

https://imgur.com/a/Mq1fWOl

After the half-mangled message appears, I can swipe to move it a little bit, causing it to cleanly refresh (also shown in the brief clip).

Not a huge deal for my day-to-day usage, although I did have it happen once with a confirmation dialog, so I couldn't read the "yes/no" option buttons until I carefully moved the dialog a bit.

[snelg]

Oh, I should clarify that this weirdness did not happen with KOReader v2020.12.

[raisjn]

can you test once more with KOReader v2020.12 to verify that it works there? it is likely a problem with rm2fb that was exposed in a recent KOReader update, but just want to double check. if anything changed in KOReaders mxcfb code this past month, that could be related.

it is likely that we will want to enable debugging mode to see the updates being sent by the client shim and the updates received by the server and then analyze what happens when opening a dialog.

is there a task you are tracking this with in KOReader?

[snelg]

Downgraded koreader to v2020.12, leaving the rm2fb libraries untouched. Problem disappeared. Re-upgraded koreader to v2021.01.1 and the problem re-appeared.

Oh, and I remembered the specific confirmation dialog that's unreadable:

• long-press a book title
• press "Delete"
• The "Are you sure you want to delete this file?" dialog is mangled

Since reMarkable wi-fi wasn't yet implemented in koreader v2020.12, that "delete" dialog is the easiest reproducible test for both versions.

By "enable debugging mode" do you mean just in koreader, or in the rm2fb libraries as well? I'm happy to keep testing/debugging, but I might need a little more n00b guidance :) Do I need a debug-enabled build of the libraries?

No, I had not yet created an issue in the KOReader github project. I wasn't sure if it was good manners to immediately create an issue in both projects at the same time, since I wasn't sure where the actual problem is.

[Eeems]

Since reMarkable wi-fi wasn't yet implemented in koreader v2020.12, that "delete" dialog is the easiest reproducible test for both versions.

I'm not seeing adding support for wifi on the reMarkable in the v2021.01 or v2021.01.1 release notes. Upon reviewing source I do see code for handling wifi. That said I'm not sure it's going to play nice with Oxide or Xochitl.

No, I had not yet created an issue in the KOReader github project. I wasn't sure if it was good manners to immediately create an issue in both projects at the same time, since I wasn't sure where the actual problem is.

Usually not that big of an issue if you track on both projects if you aren't sure where it's coming from.

[snelg]

I'm not seeing adding support for wifi on the reMarkable in the v2021.01 or v2021.01.1 release notes. Upon reviewing source I do see code for handling wifi. That said I'm not sure it's going to play nice with Oxide or Xochitl.

https://github.com/koreader/koreader/releases/tag/v2021.01 "The quite active reMarkable community has added initial support for the reMarkable 2 (#6992, #7066, #7065, #7122)." PR 7122 is the wifi one. It didn't get separately listed in the "Some highlights" list in the release notes.

I don't know if it plays nice with Oxide, since I don't use it. But everything seems to work okay when switching back and forth between KOReader and Xochitl.

[raisjn]

@snelg i just glanced through the commit log, thanks for adding the rM2 features to KOReader!

i think that it is possible that KOReader is using the "wait for update" ioctl which is not yet implemented in rm2fb. its connected as mech_wait_update_complete in koreader-base, not sure what it is exposed as in lua.

one thing to do is test on rM1 to verify the behavior is working there (which i think it will be). for debugging purposes, there is a DEBUG flag: https://github.com/ddvk/remarkable2-framebuffer/blob/master/src/client/main.cpp#L136 in rm2fb. setting DEBUG will show client:sync when the wait for last update ioctl is sent and it will show the dirty rectangles (in the server) sent by the client.

[snelg]

I don't have an rm1 to test with, so someone else will have to look at that.

I built rm2fb with DEBUG flag defined. Here are the output differences when I press the "Delete" button in the long-press book title popup.

	v2020.12	v2021.01.1
client	1612126326781 MSG Q SEND 492 769 418 95 1612126326844 MSG Q SEND 138 589 1127 694	1612126804839 MSG Q SEND 492 769 418 95 1612126804884 MSG Q SEND 147 589 1110 694 CLIENT: sync 1612126804945 MSG Q SEND 492 769 418 95
server	0ms MSG Q RECV 492 769 418 95 Dirty Region: 492 769 418 95 doUpdate mxc: waveform_mode 1 mxc: update mode 0 mxc: update marker 20 final: waveform 1 flags 4 1612126326784 Total Update took 0.00269026s 0ms MSG Q RECV 138 589 1127 694 Dirty Region: 138 589 1127 694 doUpdate mxc: waveform_mode 3 mxc: update mode 0 mxc: update marker 21 final: waveform 3 flags 0 1612126326866 Total Update took 0.0226043s	0ms MSG Q RECV 492 769 418 95 Dirty Region: 492 769 418 95 doUpdate mxc: waveform_mode 1 mxc: update mode 0 mxc: update marker 4 final: waveform 1 flags 4 1612126804840 Total Update took 0.000655046s 0ms MSG Q RECV 147 589 1110 694 Dirty Region: 147 589 1110 694 doUpdate mxc: waveform_mode 3 mxc: update mode 0 mxc: update marker 5 final: waveform 3 flags 0 1612126804909 Total Update took 0.0252073s 0ms MSG Q RECV 492 769 418 95 Dirty Region: 492 769 418 95 doUpdate mxc: waveform_mode 3 mxc: update mode 0 mxc: update marker 6 final: waveform 3 flags 0 1612126804949 Total Update took 0.00112354s

(Visual reference, showing v2021.01.1: https://imgur.com/a/ack5fMa )

[raisjn]

i think it must be the wait ioctl ("CLIENT: sync"). we can put a small sleep (500ms - 1s) in the wait for update ioctl (also in the client cpp file linked above) which would reduce the frequency of this happening, but long term we will have a way for server to signal to clients when an update is completed.

[snelg]

Yes, your suggested quick-and-dirty hack works well enough for my purposes. https://github.com/snelg/remarkable2-framebuffer/compare/d65a6e0...e985a6e

Even as low as 100ms worked for my personal test cases, so that's what I'm using on my rm2 for now. But I only use KOReader, so my test cases are fairly limited.

[raisjn]

working on https://github.com/ddvk/remarkable2-framebuffer/pull/45 which follows the semaphore idea in #44

[snelg]

working on #45 which follows the semaphore idea in #44

Cool. Let me know if you want me to test or anything.

[raisjn]

that would be really helpful! i didn't want to ask before being sure it works relatively well (and gets code review), but if you have cycles, i'm happy to have help

[raisjn]

this is now merged into toltec stable