Support for remarkable paper pro

[DanielBrosch]

I just got my paper pro, and wanted to setup rmview on it. After switching to developer mode and setting up SSH access, I get the following error:

[INFO] Detected SW version: 2.9.1.9999
[INFO] Detected device: reMarkable Ferrari
[ERROR] Device is unsupported: 'reMarkable Ferrari' [unknown device]

Anything I can do to help make this work? I use rmview quite frequently with my remarkable 2, and would love to use it with the paper pro as well.

[DanielBrosch]

This is how it currently looks when ignoring the version check:

[psilospore]

I can't even connect and see this error:

[jnickg]

Seeing the same behavior as @DanielBrosch when I hack past the version checking. I will try to spend some time investigating potential causes, but I'd be interested to hear if @bordaigorl has any thoughts or hints.

[bordaigorl]

Thanks for the reports. Unfortunately I do not own a Remarkable Pro, so I can only take a guess. From the screenshot it looks like the rM Pro is using a different encoding of the pixels, and/or not communicating the size of the screen correctly. I don't know if there's a bug in rmview's logic or if it's just the rM pro's VNC server not giving the right information. Essentially, after connection, the protocol the rM is using to transmit the data should include information about how the data is encoded and the screen geometry. Either this info is not given correctly, or they are using some custom encoding which is not supported by rmview, or rmview is somehow misinterpreting the data.

[leoluk]

@bordaigorl If the community buys you a Remarkable Pro, would you be interested in implementing support for it? :-)

[bordaigorl]

@leoluk well, that would be very generous and would indeed give me motivation ;) The situation is as follows: in my own workflow I rely on rmview and remy. At some point I had to stop updating my firmware on RM1 (I'm still on 2.15) because I could not keep up with all the changes. For remy that's mostly due to the new file formats (I have a ton of ideas for remy which I can't justify working on because of the instability of the format/platform). For rmview the problem is that 1) they use a custom VNC modified with some custom gatekeeping which is hard to get around 2) there are differences between RM1/2/pro which I cannot test directly 3) they keep making weird breaking changes. My main pain point is the authorization phase, which requires the RM to be logged into the RM account for the screenshare to work. I even implemented a backend in a separate branch that uses restreamer on the tablet, and it works reasonably on RM1 but I can't make it work on RM2/pro without other people testing it for me.

For this specific bug, it would seem it's just a matter of finding the right encoding, so indeed having access to a RM pro would likely be enough, but it's hard to say if I can keep maintaining it chasing whatever changes they make...

[SohnyBohny]

Some more observations:

As @DanielBrosch's screenshot already shows, only a part of the screen is streamed and the aspect ratio is broken.

Regarding the aspect ratio:

• when you draw something the aspect ratio is right
• only after a screen refresh things get expanded in horizontal direction by a factor of two
• on the initial start of rmview the aspect ratio is broken too
• to conclude: the aspect ratio is correct only at the moment you are drawing, else it is stretched by a factor of two in horizontal direction

Regarding the part of the screen that is streamed:

• while drawing the upper left 155 mm x 207 mm are streamed
• I don't have an reMarkable 2 but according to the internet this roughly seems to be the size of its screen
• After a display refresh only 77.5 mm x 207 mm are streamed
• (numbers are only estimates)
• Edit: The screen size in pixels is hard-coded here changing it to 1620 x 2160 pixels fixes this part.

Truth	Fresh drawing	After refresh

Additionally, colors are broken – but I guess fixing them is only the second step.

Do you have some pointers to the relevant parts of the code I could play around with?

[wormyrocks]

On RMPP v3.17, I dumped the FB parameters from _handleServerInit thinking maybe they would help provide some clues to interpret the framebuffer data properly.

width:  1620
height:  2160
namelen:  14
bpp:  16
depth:  16
endian:  0
truecolor:  1
redmax:  31
greenmax:  63
bluemax:  31
redshift:  11
greenshift:  5
blueshift:  0

And here is a hex dump of the raw data passed into _handleServerInit:

00000000: 0654 0870 1010 0001 001f 003f 001f 0b05  .T.p.......?....
00000010: 0000 0000 0000 000e                      ........

LMK if there's anything else i can try. I also have an RM1 on hand but am quite new to the ecosystem.