Not working on reMarkable2 version 3.6

[greglearns]

reMarkable2 version 3.6.0.1806
goMarkableStreams version 0.10.0 and 0.9.0
was able to ssh into the remarkable and run the ./goMarkableStream and connect to it from my laptop browser (entering admin/password), but in both cases there was the gray screen of noise with continual moving noise.
Perhaps they changed the frame buffer again?

[owulveryck]

ah zut! (first French words that came out of my mouth :))

I will have a look, but not until a couple of weeks due to vacations.

Meanwhile, if you want, you can try to extract an image manually to see if things have changed.

You can find some pieces of information to do that here.

Thank you for raising this issue.

[2Belette]

Thanks for the project! works fine on 3.5, will stay on that version for now :)

[owulveryck]

For those who want to help and find the new version of the picture, I have uploaded the full content of the memory area of the framebuffer here

[owulveryck]

First basic investigation: there is a possibility that they changed their implementation to use Partial framebuffer

[dividuum]

I accidentally toyed around a bit to much trying to get this to work and ended up with a quick and dirty solution that works on my remarkable 2. It seems there still is a linear frame buffer: Given

6e0fa000-6f8b8000 rw-s a9d00000 00:06 7565       /dev/fb0

the base address is 0x6f8b8000 + 1872*1404*2. I'm not sure I understand why it works when using the end of that mapping plus an offset, but 🤷. Each pixel is then represented by two bytes. I'm using the second byte as a direct value for r, g and b in the canvas. I'm also using gzip instead of the RLE encoding using minimal compression, so see if that is viable. Feel free to take whatever you need from my code as I don't plan on maintaining it.

[owulveryck]

Awesome.
Thank you very much.
About the gzip compression, do you see any overhead in the CPU usage compared to the minimum RLE ? I guess that the amount of data to be transfered is very low with this ?

[dividuum]

Didn't compare CPU usage, but I explicitly used the minimum compression level of 1 (see here for example for some graphs) to make it as fast as possible while still benefiting from compressing down the raw 5.2MB frame to something around 100kb for most content I'm displaying. I mostly chose gzip as I assume (wrongly?) it has a somewhat optimized implementation as it is also used in other contexts and it doesn't need an extra decoder when rendering the content as the browser will happily do the decompression for me.

That said: Maybe brotli would be even better (see https://timmehosting.de/brotli-vs-gzip), but I opted for an algorithm that doesn't require external go dependencies.

[owulveryck]

Thanks to your help, I was able to extract a picture from the memory with this code:

package main

import (
	"image"
	"image/png"
	"log"
	"os"

	"github.com/owulveryck/goMarkableStream/internal/remarkable"
)

func main() {
	f, err := os.Open("../testdata/full_memory_region.raw")
	if err != nil {
		log.Fatal(err)
	}
	defer f.Close()
	backend := make([]uint8, remarkable.ScreenWidth*remarkable.ScreenHeight*4)
	n, err := f.ReadAt(backend, 0)
	if err != nil {
		log.Fatal(err)
	}
	log.Printf("read %v bytes from the file", n)
	boundaries := image.Rectangle{
		Min: image.Point{
			X: 0,
			Y: 0,
		},
		Max: image.Point{
			X: remarkable.ScreenWidth,
			Y: remarkable.ScreenHeight,
		},
	}
	img := image.NewGray(boundaries)
	for i := 0; i < remarkable.ScreenHeight*remarkable.ScreenWidth*2; i += 2 {
		img.Pix[i/2] = backend[i] << 4
	}
	png.Encode(os.Stdout, img)
}

The trick is actually to get one byte out of two, and I don't know why (neither I know what is the other byte used for).

I notice that there is no need to move the offset; I guess the picture is present several times in the memory for refresh function internally.

[owulveryck]

I have created branch fw3.6.
So far, without RLE, I can make it work. I guess that the pixels are not uint4 anymore.

Funny stuff, the image is flipped.
I will try the second buffer (with the address mentioned in the previous comments)

[owulveryck]

I noticed two things in my exploration:

• there is a kind of magic number on the 8 first bytes of the picture [0 0 0 0 2 64 80]; skipping them should fix Landscape orientation is off by a few pixels #56
• seeking for this signature leads to a second picture in the memory at 187214042+something... at this position, the picture is not WidthHeight, but HeightWidth and not in uint4.

[AngleOSaxon]

For the wildly impatient yet lazy (such as myself), I made a quick hack branch that fixes the image-flipping issue (badly) in Javascript: https://github.com/AngleOSaxon/goMarkableStream/tree/fw3.6_rotation_hack

Not the most efficient solution, but it works.

[owulveryck]

Cool.

I fixed the flipping in the fw36 code now (as I need to extract one out of two pixels, I take the opportunity to place them in the correct index on the backend).

I still need to tweak the rendering and the fw36 will be almost ready.

I have to evaluate the impact of the change because it will require a lot of memory to process. But I think I cannot do better for now.