Closed danshick closed 3 years ago
Just read #28 again and thought I could do something similar by reading from data in libremarkables framebuffer which, when LD_PRELOAD is used, would interact with rm2fb as well.
This solution however is even better! Please someone with a rM 2 device and some apps that use rm2fb check this out!
Please someone with a rM 2 device and some apps that use rm2fb check this out!
When writing this PR, I had access to an rM2. This worked with and without rm2fb installed. I didn't test on an rM1 yet. Would love if people with either version could test and confirm.
Works on my rM 1. :+1:
Installation with toltech doesn't work yet. I guess this is because toltech is downloading from the main branch, and this PR is not yet merged. :)
Installation with toltech doesn't work yet. I guess this is because toltech is downloading from the main branch, and this PR is not yet merged. :)
It is available in toltec-testing, but yes, we are building a specific commit from master. It'll need to be updated once this PR is accepted.
Installation with toltech doesn't work yet. I guess this is because toltech is downloading from the main branch, and this PR is not yet merged. :)
It is available in toltec-testing, but yes, we are building a specific commit from master. It'll need to be updated once this PR is accepted.
Should be in stable on Monday: https://github.com/toltec-dev/toltec/pull/204
Installation with toltech doesn't work yet. I guess this is because toltech is downloading from the main branch, and this PR is not yet merged. :)
It is available in toltec-testing, but yes, we are building a specific commit from master. It'll need to be updated once this PR is accepted.
Sorry, what I mean is that if installed from toltech-testing, it doesn't work anyway because until this PR is merged the wrong executable is being built. :)
Hey everyone. Since the branch is not yet merged, I'm trying to compile the code myself, but not being fluent in rust it's quite the headache for me.
As we wait for the merge, would it be possible to update the executable in this branch to reflect the new code, so that users that want to test it can just clone the repo and copy the right executable over to their remarkable?
As we wait for the merge, would it be possible to update the executable in this branch to reflect the new code, so that users that want to test it can just clone the repo and copy the right executable over to their remarkable?
I should have done that, but chose not to because I don't use the official remarkable toolchain, and I didn't want to include a binary that is built differently than @rien does it.
What I'll probably do instead is open a PR in toltec to build this fork (temporarily) and let toltec's CI system build and package it for me. Then you'll be able to download an ipk and install it with opkg.
I won't have time today or tomorrow, so might be a couple days.
Hi,
I don't think that a PR that isn't in the official software should be added to toltec, since it is supposed to have stable releases of all the software.
However, I took the liberty to just modify the current package file in toltecs testing branch to point to the latest commit of this PR and make a local build with that.
Here is the (unofficial) ipkg file for this branch (zipped and also contains the modfied package file): 📎 restream_0.0.0-1_armv7-3.2.ipk.zip
One can just extract the binary and probably attach it to this branch. It is located in opt/bin
of the data.tar.gz inside of the ipk file which is just an archive as well.
So once this PR gets merged, it will also get added to toltec (best by the person who did it the first time, but I could do it as well).
This works like a charm, thanks!
@rien, are there any changes you'd want to make for this PR? I'm happy to work with you to get it to a place your happy with.
Thank you for your contribution. I'll make a few other changes and then I'll create a new release.
I've moved release preparations to PR https://github.com/rien/reStream/pull/49.
Thanks!
Same as #39, but more "main".