Support for the Remarkable 2
phaer opened this issue · comments
From a cursory glance, it seems like libremarkable does not support the Remarkable 2 yet, is that correct?
It looks like https://github.com/canselcik/libremarkable/blob/master/src/framebuffer/mxcfb.rs uses the mxcfb Framebuffer driver from the SDK for Remarkable 1, while Remarkable 2 uses a different driver koreader/koreader#6792
That would be correct. There are no third party applications for the reMarkable that can use the screen on the rM2 yet.
We should probably wait on the results of ddvk/remarkable2-framebuffer . It's mainly a joint effort of @ddvk and @raisjn who have already a working PoC but are trying to find the best solution for the entire ecosystem. Though they might also provide a fake fb0 for us to use (the actual fb0 returns insane data according to @raisjn).
We will likely need to turn the Framebuffer into a client that will communicate with their lib via IPC. Not sure whether they'll support the rM1 framebuffer, but my guess will be that we keep this implementation for more flexibility as well.
EDIT: The #rm2 channel on the discord has most disussions and insights atm.
@LinusCDE / @Eeems : could you please send me an invite to discord?
@Witos There is a link in the readme here: https://github.com/Eeems/oxide/
Since PR #48 got merged now, using the lib (probably still from git) along with the framebuffer shim, should produce working rust apps again.
@LinusCDE Do I need to change anything in this repo to make it work on Remarkable 2? How do I use the files you mentioned? The files are cpp but this repo is in rust.
take a look at the readme in the root of that repo.
you need to 1) stop xochitl, 2) start rm2fb server and 3) launch your app using the preload shim.
this process will be more streamlined in the future,but let us know if you have any problems getting started
@LinusCDE Do I need to change anything in this repo to make it work on Remarkable 2? How do I use the files you mentioned? The files are cpp but this repo is in rust.
This repo should now support the inputs of the new remarkable nativly. The framebuffer is not really touched at all and doesn't work on the rM2. That's where the shim comes in. It's basically a sniffer, that catches all syscalls to the /dev/fb0 file/device and instead does working calls working calls the the framebuffer that work on the new device. Keep in mind though, that selecting most or all waveforms and refresh modes will mean little to nothing the the translation library and just result in working the same performing draw calls as of now.
I'm personally not sure how to make it work either. I don't own a reMarkable 2. One author of the repo, @raisjn, helped me test previous builds, but is currently not able to.
Maybe @ddvk can give some clarification on how to get it to work. Having some runner/bootstrap script would be really nice.
Just saw @raisjn's reponse, after writing the above text.
take a look at the readme in the root of that repo.
you need to 1) stop xochitl, 2) start rm2fb server and 3) launch your app using the preload shim.
this process will be more streamlined in the future, but let us know if you have any problems getting started
Just checked the Building section of the mentioned repo. Seems that running this should be straight forward to me at least. It compiled fine for me. Maybe adding a release with the binaries only could help for people who don't have all the toolchains set up.
If it helps, here the current src that also contains the compiled output:
remarkable2-framebuffer.tar.gz
@lapwat The latest releases of my two rust apps, also use the current state of libremarkable. If you have some time, it would be nice if you could check that they run on the rM2 with the shim. (inputs should not be inverted and such) and drop a comment to the respecive PRs to toltec. It's not urgent at all though.
@lapwat The latest releases of my two rust apps, also use the current state of libremarkable. If you have some time, it would be nice if you could check that they run on the rM2 with the shim. (inputs should not be inverted and such) and drop a comment to the respecive PRs to toltec. It's not urgent at all though.
Not sure how to do that. I just have to put the binary on my RM2 and execute ./chessmarkable ?
I don't want to brick it I will wait for end to end documentation to be available somewhere. That way I'll be more confident to try such experiences 🤔
@lapwat It would be pretty much what you said. Only the shim would have to be prepended or you'd get no image.
I don't think that the binaries could brick your device. No guarantee though as I don't own a device myself. And I can understand your caution to run random stuff.
@raisjn has tested it anyway. Seems that the Multitouch has a wrong rotation on the rM 2. I don't know, which the correct one is, yet.
If you find it out @lapwat, that would be great (just if you have the time and motivation). Would be changing the rotation in src/device.rs and checking whether the compiled input example registers touch input at (nearly) 0, 0 when touching the top left corner of the screen. Would be an easy bug fix PR.
Last week I had tried the feature/rm2-input branch and had to change the rotation to 180, and change line 138 of multitouch.rs to
CoordinatePart::X(&SCANNED.multitouch_orig_size.x - (ev.value as u16)),With these changes the demo worked. I had also tried retris before making these changes, and everything worked except for touch.
Last week I had tried the
feature/rm2-inputbranch and had to change the rotation to 180, and change line 138 ofmultitouch.rstoCoordinatePart::X(&SCANNED.multitouch_orig_size.x - (ev.value as u16)),With these changes the demo worked. I had also tried retris before making these changes, and everything worked except for touch.
Thanks for testing it out!
Have you tested, whether the Rot0 or Rot90 worked without modifying this? I'm pretty sure that I tested the hell out if it. I even wrote a test to ensure it works as intended since creating that was a really annoying and I wanted to spot any mistakes or future ones with that.
It no rotation works, I'll probably have to dig into it again, as this change might break the rotation for the rM 1's touch input.
The input example binary is probably the easiest for testing out the input since it just spits out all events and some additional debug info.
I didn't try 0 or 90 degrees, but wouldn't that put 0 for the y axis in a different corner? I don't have a remarkable 1 to compare with, but I've read that remarkable 2 switched the x axis direction.
I might have time later this week or next week to test it more.
I now have both rm1 & rm2 and have successfully tested my whiteboard app on both (using the shim on rm2).
However I would prefer not have to use a shim at all on rm2. I'd rather have an implementation in libremarkable directly so as to only have to build one binary and not have to pay a potential communication penalty. From there we can think of what the app should do if a fb server is running or something. But maybe you believe this is not the way to go?
Such an implementation isn't here yet, right?
BTW I used the binaries at https://github.com/ddvk/remarkable2-framebuffer/releases/tag/v0.0.1
Since the shim is a client server model, libremarkable would be required to include the client code inside it, and would need to be updated at the same time as rm2fb if the communication ever changes. Likely using the shim is still the best option.
I think having openssl's aproach would be great: https://docs.rs/openssl/0.10.30/openssl/#vendored. That way, anyone using libremarkable can decide whether he expects a device to have the lib, or get it automatically included. (I had planned and tested to use the vendored openssl to have https support on the device since a proper openssl lib is missing).
As for the implementation with the shim, I imagine a Shim-Framebuffer or Layer that redirects all write and IoCtl calls to the shim library (which would probably need some kind of interface to the openas, ioctl and other hooks for that). At that point, libremarkable wouldn't require a LD_PRELOAD and could use the lib as described above.
For my own software, I would probably want to statically compile the lib into my binary for standalone releases and link it dynamically for toltec releases where I would depend on rm2fb.