Does not work with my version of Xochitl

[raisjn]

This issue is for when rm2fb's server process fails to find the signature it needs.

Please respond with which binary was being used and what its md5sum is, thank you!

NOTE: this issue is specifically for if rm2fb server or client prints out an error referencing issue #18. The error message means that the signatures we use are no longer valid in the version of xochitl being used. Please open separate threads for other issues.

[mihai-satmarean]

HI, following this thread: matteodelabre/vnsee#21 (specifically matteodelabre/vnsee#21 (comment)) I managed to have a confirmed connection from remarkable 2 version: 3.4.0.1771, the issue I am having seems to lead here and is:

reMarkable: /root/ LD_PRELOAD=/root/librm2fb_server.so.1.0.1 /usr/bin/xochitl
STARTING RM2FB
Missing address for function 'getInstance'
PLEASE SEE https://github.com/ddvk/remarkable2-framebuffer/issues/18

and when running the client

reMarkable: /root/ LD_PRELOAD=/root/librm2fb_client.so.1.0.1 ./vnsee
Connecting to 10.11.99.2:5900
Warning: The server resolution (1728x1117) does not fit in the screen (1404x1872)
The image will be cropped to fit
Connection established

I am running Mac Ventura 13.2 on an M1 Max chip.
Any hint appreciated!

[Eeems]

I am running Mac Ventura 13.2 on an M1 Max chip.
Any hint appreciated!

See the comment just before yours.

[mihai-satmarean]

Thanks, I already browsed this for like an hour and it escapes for me a simple answer: it works, it does not work, it will work...

[phaer]

Thanks, I already browsed this for like an hour and it escapes for me a simple answer: it works, it does not work, it will work...

In my understanding 3.2.3.1595 is the last version reported to work here, 3.3+ are not supported and still require outstanding changes. That includes your 3.4.0.1771.

[mihai-satmarean]

Thank you! Then I guess we will get notified for changes when something happens here? I was pretty excited to get it running... Now I need a beer :)

[mihai-satmarean]

Dirty support for 3.3-only on rm2: https://github.com/Witos/remarkable2-framebuffer/tree/witos/support-3.3

3.4 in sight?

[mrbadduck]

Upvote request for support. I'm on 3.5 now 😬

[timower]

FYI I have a version of rm2fb that works for 3.5: https://github.com/timower/rM2-stuff/tree/master/libs/rm2fb
in 3.5 the 'create threads' function is inlined into the 'create instance' function, which meant some manual hooking was needed:
https://github.com/timower/rM2-stuff/blob/6eb432cd61565fa8a1ae326914385b016186ca24/libs/rm2fb/AddressHooking.cpp#L24

[juanfcocontreras]

FYI I have a version of rm2fb that works for 3.5: https://github.com/timower/rM2-stuff/tree/master/libs/rm2fb
in 3.5 the 'create threads' function is inlined into the 'create instance' function, which meant some manual hooking was needed:
https://github.com/timower/rM2-stuff/blob/6eb432cd61565fa8a1ae326914385b016186ca24/libs/rm2fb/AddressHooking.cpp#L24

Could you share a release version (.so) to test it?

Thank you in advance!

[timower]

https://github.com/timower/rM2-stuff/releases/tag/v0.0.10
Has an ipk you can install (includes all rm2-stuff apps though) and the raw so files if you want to test.

[juanfcocontreras]

https://github.com/timower/rM2-stuff/releases/tag/v0.0.10 Has an ipk you can install (includes all rm2-stuff apps though) and the raw so files if you want to test.

Raw files seems to be working great on my 3.5 and KOReader!

Thank you so much @timower !!!

[Cyrus-Harding]

https://github.com/timower/rM2-stuff/releases/tag/v0.0.10 Has an ipk you can install (includes all rm2-stuff apps though) and the raw so files if you want to test.

How would you install the IPK, file? Toltec says there's a dependency conflict.

[timower]

What's the conflict?

[Cyrus-Harding]

What's the conflict?

[phaer]

Just a word of warning, when I first started xochitl after adding an LD_PRELOAD with the .so from rm2stuff, my remarkable rebooted und is in a loop since then. Don't yet understand exactly what triggered it and might be specific to me device, have to wait until my pogo pin connector gets delivered to find out 😅

[Eeems]

Just a word of warning, when I first started xochitl after adding an LD_PRELOAD with the .so from rm2stuff, my remarkable rebooted und is in a loop since then. Don't yet understand exactly what triggered it and might be specific to me device, have to wait until my pogo pin connector gets delivered to find out 😅

If you don't have the rm2fb server running, the xochitl service will crash when running with the LD_PRELOAD. When the xochitl service crashes it will restart itself and run a script to keep track of how often it crashes. That script will switch the root partition to the fallback one if it is run too many times in a short period of time. If your fallback partition is also in a bad state you can get yourself into a reboot loop.

[NickHu]

@timower Could you please share which version of 3.5 your fork of rm2fb works on? I got a segfault with 3.5.1.1798 which was my best guess to the one that you support, as indicated by:
https://github.com/timower/rM2-stuff/blob/658d382bbe0778fccad32baab1350c7cf9c4eb00/libs/rm2fb/Address.cpp#L117

(Although I don't know how to translate between the two different formats of version numbers that seem to be in use.)
I also tried 3.5.2.1807_reMarkable2-3bZjC0Xn5C-.signed but that didn't work either.

[timower]

3.5.2.1807 is what I'm using. It's also what https://github.com/timower/rM-docker uses, so it should work.

[Haspamelodica]

I'm running 3.7.0.1930; the sha256sum of my xochitl binary is 4da8f2f770f1222f82613de577d86f22178100259455a839d877375e6f1e0036. It seems the binary contains none of the strings mentioned in the tutorial, and I can't even find any similar strings, except for "Shutting down". Also, I can't find a function looking similar to how wait() is shown in the tutorial. The same is true for the functions as documented in @timower's rm2fb version - I can't find any of them.

Does this mean that the structure of xochitl changed entirely since the last version which rm2fb supported? If so, is it feasible to make rm2fb work with the newer versions? Or am I just too inexperienced to be able to identify these functions?

[Haspamelodica]

Forgot to mention: The original /etc/version file of that update says 20180309123456, but I overwrote that with 20230824123456 according to bordaigorl/rmview#146 (comment).

[Eeems]

reMarkable has started to use reproducable builds for their OS releases, so /etc/version will no longer be unique per-version. At least that's what was indicated in discord by one of their staff. So going forward, a new mechanism will be required for determining the OS version.

3.6 and newer have had large changes, including libc upgrades, so it's quite likely that a bunch of how the display code works changed, and further code changes will be required for rm2fb to work.

[Eeems]

Part of the other difficulty here is that rm2fb is being maintained in a backwards compatible way. Which means that every new release must still support the older OS versions with the built in config. This is why we can't just take timower's implementation and call it a day, as that is not backwards compatible, and it would not work on older OS versions.

As soon as toltec breaks up it's OS version support so that different sets of packages can be used on different OS versions, we can explore dropping older OS version support from rm2fb, but it's taking a while because it's difficult to get people to test the open PRs against toltec, which is required before we can merge them.

[Groxx]

(sorry, I removed that reply - feel free to restore if you want, I just found it less accurate than I thought after poking at the different forks)

So is it mostly a distribution issue then? The technical side is working, backwards-compat with existing uses is working, but it needs to be made to work with all xochitls to distribute safely? (or toltec changes, but that's outside of this repo)

Is there anything technically preventing that, or is it mostly a "needs more effort" thing, to support both sets of method names/etc and select the correct one at runtime [somehow]? If it just needs to support both, that can probably be done by someone who doesn't have reverse-engineering experience.

[Eeems]

(sorry, I removed that reply - feel free to restore if you want, I just found it less accurate than I thought after poking at the different forks)

I'd recommend just adding an edit instead of removing a comment in the future. I don't have permissions to restore deleted comments.

So is it mostly a distribution issue then? The technical side is working, backwards-compat with existing uses is working, but it needs to be made to work with all xochitls to distribute safely?

Is there anything technically preventing that, or is it mostly a "needs more effort" thing, to support both sets of method names/etc and select the correct one at runtime [somehow]?

Yes and no, we'll still need to resolve some backwards compatibility issues as toltec is just splitting down the OS 2.x and 3.x line so far. Which will mean that rm2fb will still need to support all of the 3.x side, which is still something that requires porting of the other forks code.

This is difficult, as timower's code, which is the one that is updated the most, has done extensive changes that will be difficult to port into the existing rm2fb code. Existing 3.2 and 3.3 support that was released in rm2fb took a bit of effort to be ported in.

I'm also not sure we have full coverage of the stable OS builds handled yet. So there is still more work that would be required after porting changes into rm2fb's codebase to make sure those OS versions will work.