rm2fb waveforms don't support qtswikipedia

[raisjn]

from @dps: remarkable-wikipedia doesn't show links correctly.

https://rmkit.dev/rm2fb/qtwikipedia <--- test binary with built in page
https://rmkit.dev/rm2fb/qtwikipedia.png <--- what is in the buffer

but what shows up on screen is that the link is invisible.

i tried using waveforms 0, 1, 2, 3 and none of them showed the link for me

[NiLuJe]

That would hint at A2/DU being used. GL16/GC16 should handle this just fine. And AUTO should make the right choice on its own, too.

Which probably indicates that something changed in the EPFrameBuffer API or something, because I assume the stock software does have the ability to display more than 2 or 4 shades of gray ;)?

[NiLuJe]

Has there been any communication on rM's part about an updated SDK for the rM2? So we'd get to see the new version of this.

[Eeems]

Yes, they've released it: reMarkable/linux#7. It doesn't have any libraries for interacting with the framebuffer. Just the old rM1 libraries.

[NiLuJe]

Huh, yeah, same old version of that header :/.

[raisjn]

reMarkable: ~/rm2fb/ bash run.sh ../qtwikipedia
STARTING RM2FB
ADDR: 21f54
EPD platform plugin loaded!
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
Reading waveforms from /usr/share/remarkable/320_R299_AFC421_ED103TC2U2_VB3300-KCD_TC.wbf
Running INIT (111 phases)
SWTCON initialized \o/
INSTANCE ADDRESS: 0x41754
EPFramebuffer
Methods
2 "deleteLater" () ()
2 "clearScreen" () ()
2 "sendUpdate" ("rect", "waveform", "flags") ("QRect", "EPFramebuffer::WaveformMode", "EPFramebuffer::UpdateFlags")
2 "sendUpdate" ("rect", "waveform") ("QRect", "EPFramebuffer::WaveformMode")
2 "sendUpdate" ("rect", "waveform", "mode", "sync") ("QRect", "EPFramebuffer::WaveformMode", "EPFramebuffer::UpdateMode", "bool")
2 "sendUpdate" ("rect", "waveform", "mode") ("QRect", "EPFramebuffer::WaveformMode", "EPFramebuffer::UpdateMode")
2 "waitForLastUpdate" () ()
2 "sendUpdate" ("region", "waveform", "flags") ("QRegion", "EPFramebuffer::WaveformMode", "EPFramebuffer::UpdateFlags")
2 "sendUpdate" ("region", "waveform") ("QRegion", "EPFramebuffer::WaveformMode")
2 "clearGhosting" () ()
1404 1872 16
OPENED SHARED MEM: /dev/shm/swtfb.01 at 718b6000, errno: 0
WAITING FOR SEND UPDATE ON MSG Q
EPD platform plugin loaded!
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
Creating window
qrc:/main.qml:39: TypeError: Cannot read property '1' of null
Framebuffer has wrong id: "mxcfb"
Framebuffer initialized: QImage(QSize(1404, 1872),format=7,depth=16,devicePixelRatio=1,bytesPerLine=2808,sizeInBytes=5256576) 5256576
Dirty Region: 0 0 1404 1872 3

two pieces of note are:

1. dirty region's last parameter is the waveform mode - 3 - being sent through mxcfb_update. even if i try out hardcoding waveform mode to use, i can't seem to get the link to display. it seems only modes 0 to 3 are supported through sendUpdate API, i get an error if i use other numbers
2. the list of methods look similar to the previous epframebuffer.h

in KOReader+rm2fb, book cover images look fine to me - but maybe i should try using a test image that i know what its supposed to look like.

[NiLuJe]

EPFramebuffer::UpdateFlags is new and nowhere to be seen in the "updated" SDK... :D.

[NiLuJe]

AFAICT, 0 shouldn't actually work. It's INIT, which should do a flashing clear to white or... something, it's generally not to be used outside of right after bringing the EPDC up.

You generally want 1 (DU), 2 (GC16) or 3 (GL16).

    enum WaveformMode {
        Initialize = INIT,
        Mono = DU,
        Grayscale = GL16,
        HighQualityGrayscale = GC16,
        Highlight = UNKNOWN
    };

322677   │  <3><535e5>: Abbrev Number: 5 (DW_TAG_enumerator)
322678   │     <535e6>   DW_AT_name        : (indirect string, offset: 0x1b389): Initialize
322679   │     <535ea>   DW_AT_const_value : 0
322680   │  <3><535eb>: Abbrev Number: 5 (DW_TAG_enumerator)
322681   │     <535ec>   DW_AT_name        : (indirect string, offset: 0x3da54): Mono
322682   │     <535f0>   DW_AT_const_value : 1
322683   │  <3><535f1>: Abbrev Number: 5 (DW_TAG_enumerator)
322684   │     <535f2>   DW_AT_name        : (indirect string, offset: 0x4d39c): Grayscale
322685   │     <535f6>   DW_AT_const_value : 3
322686   │  <3><535f7>: Abbrev Number: 5 (DW_TAG_enumerator)
322687   │     <535f8>   DW_AT_name        : (indirect string, offset: 0x4026d): HighQualityGrayscale
322688   │     <535fc>   DW_AT_const_value : 2
322689   │  <3><535fd>: Abbrev Number: 5 (DW_TAG_enumerator)
322690   │     <535fe>   DW_AT_name        : (indirect string, offset: 0x29c91): Highlight
322691   │     <53602>   DW_AT_const_value : 8

Which is consistent with the actual Waveform enum.

[NiLuJe]

Those constants used to match with the actual MXCFB constants: https://github.com/NiLuJe/FBInk/blob/5d5e8f0210a1afb6709c499179f1d2cacd70e0af/eink/mxcfb-remarkable.h#L139-L159

(c.f., strace logs)

[raisjn]

Dunno.

I'm able to use waveforms: 0, 1, 2, 3 and 8 (maybe 8 is debugging?).

0: slower than 1
1: DU
2: high quality (more colors)
3: less quality (less colors)
8: unsure

I thought UpdateMode -> UpdateFlags, but now not sure. If I set mode=8, updateFlags = 1, it flashes all the queued dirty regions on the screen when doing a repaint, and i can see 20 - 30 small regions (5x5) per update when drawing a line (which corresponds to the regions i'm sending over as dirty)

[NiLuJe]

You interpretation of 1, 2, 3 makes sense. 0 should be broke as all hell (or at best useless in practice), unless they fudge it internally to something else ( AUTO?).

I don't recall if we ever tested 8, but if we commented it out in FBInk, it was probably broken ;).

My best guess as far as UpdateFlags is concerned is that it's a wrapper around the EPDC_FLAG_ stuff, used e.g., for HW inversion or HW/SW dithering setup.

waitForLastUpdate probably does (did? ^^) a WAIT_FOR_UPDATE_COMPLETE on the last EPFrameBuffer update marker (which is probably what the sync bool does automatically for a specific sendUpdate).

[raisjn]

i checked master and the it still doesn't render links properly, even though multiple fixes were applied to waveform handling

[raisjn]

talking with bokluk the other day, we think that SWTCON is not properly drawing the blue channel (and ignoring some blue bits). one way to work around is to convert to grayscale before displaying in your app, the other is to fix SWTCON code itself (unlikely).

for this issue, i would consider it success when we fix qtswikipedia's links to show up

[Eeems]

@raisjn is this still an issue?

[Eeems]

@raisjn poke?