-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Doesn't work on rM2 #34
Comments
Thank you for opening the issue and for your patience while we figure out rM2 stuff! The code in this repo is not expected to work on rM2 until we figure out how to write to the framebuffer for rM2: https://rmkit.dev/news/rm2-status/ In terms of launching without the home button: when we get remux working on rM2, you can slide up the left or right side of the screen to launch it. |
also, congrats on your rM2 (and sorry rmkit isn't working yet - but it is only a matter of time) |
made some progress using ddvk/remarkable2-framebuffer rm2fb IPC server (see ddvk/remarkable2-framebuffer#9). current issues:
what works:
untested:
|
video of remux + mines + harmony + xochitl still having trouble switching back and forth between xochitl and non-xochitl apps, but its only a matter of time. |
I like ddvk's solution: use a touch gesture to go from xochitl -> launcher and launcher -> xochitl. When moving between the boundary of launcher / xochitl, the SWTCON has to get restarted, but otherwise it looks pretty smooth. One downside is that re-starting xochitl will lose your place in it (i think), so I'd like to work towards a solution that will not require restarting xochitl (perhaps just flashing the screen once or twice) |
I've been thinking about replacing /dev/fb0 with a virtual framebuffer managed by a daemon, which could facilitate multitasking in a safe way by locking the device around framebuffer updates. I might be paranoid, but this would also allow for rate-limiting updates to prevent bricking the display. |
sounds interesting. have you looked at rm2fb's architecture? It is also a server model (with a "daemon" managing the framebuffer) and clients interacting with the server through IPC. in the future, we'd like to replace the daemon's FB code with the open source FB code. it would be nice if we (anyone in the rM community) could collaborate here (either on the server model or on the open source SWTCON). in term's of the client interaction, we started with an LD_PRELOAD shim for rM1 apps (good idea, @pgaskin!) (which creates a "fake" /dev/fb0 by pretending to be there), but @pgaskin also suggested a way of making a virtual /dev/fb0 using FUSE. there are probably even more ways to create the fake /dev/fb0, but whichever way is taken, i think it's worth pursuing creating a fake /dev/fb0 for batching (it's not paranoid!), i've tried two things:
not sure if either were useful, it is hard to tell before we have fast drawing working. |
The FUSE method would be the only way (other than a kernel driver, but then you're basically reinventing the wheel) to support the normal ioctls without having control over the actual applications (e.g. LD_PRELOAD or strace) AFAIK. If the fake /dev/fb0 doesn't support the ioctls, it's arguably worse than the LD_PRELOAD shim (note that it can be directly linked into static binaries if needed) or implementing the IPC directly in applications (which I wouldn't recommend in general, since it'll restrict the changes you can make in the future) since it'll look the same but act differently. As long as the rm2 kernel supports FUSE, I'm pretty certain that idea will work well. The only thing which I'm not sure about are the implications of mmap via FUSE. Regarding the LD_PRELOAD shim: I saw your comment about it being ready for review, and I'll be getting around to doing a full review as soon as I have time. |
I think I understand the context a little better now (after re-reading the thread): Would your proposal help with xochitl -> launcher and launcher -> xochitl? Or would it help in general for multi-tasking apps? (or both?). I had wondered about giving each client its own piece of shared memory (so they can't clobber each other) and when they talk to server, their updates come from only their shared mem.
uh oh - be gentle, please 🤕 |
remarkable2 support is now available with rm2fb the current binaries on build.rmkit.dev have rm2 support. we'll update this task when the toltec packages land in testing and stable |
rmkit apps in toltec testing repo now support rm2. they will be merged into stable in the next merge window the other piece is finishing the rm2fb PR on toltec. after that, i believe rm2 support will be mostly finished |
rm2fb is in toltec stable. all rmkit apps in toltec stable now support rM2 as well, closing out |
Sorry, this might be a newbe Question: I installed remux and started the service on my new RM2. How can I open it? Sliding rupward at the sides - as explained above - shows no effect for me. |
Do you have rm2fb installed from toltec? You need rm2fb for apps to be able to draw to screen. to launch remux: you can swipe up the side of the display. the latest build (0.1.5) will also launch remux when you tap with three fingers, which will hit toltec in a day or two. |
Yes, you are right. Now it is working, thanks! |
Since toltec is also used by rM1, and rm2fb does not work on the rM1 we aren't going to be doing that. But we are looking into how to ensure that the rM2 always gets rm2fb as a base dependency. |
I just got my rM2 and tried installing. Installation went fine, but I cannot seem to bring up the launcher.
For one, there's no home button.
The text was updated successfully, but these errors were encountered: