Closed raisjn closed 3 years ago
some ideas:
Proposal for integrating rm2fb with xochitl:
Implementing this would be in two phases:
we added rm2fb inside a running xochitl in in_xochitl
branch and can get apps drawing to screen, but the process crashes (memory safety with accessing the shared framebuffer?)
we don't have specific repro step yet, just seems to happen after second app draws to screen and xochitl writes again
for the qt hooking, as we discussed on discord, makes sense to hook a function (with ldpreload) called in the qt main loop instead of recompiling qt
timower got a prototype working (based on Antarctica's design but no qt recompile): https://github.com/timower/remarkable2-framebuffer
there is small issue with events being sent to xochitl after its unpaused but that can likely be solved with event filter or otherwise
I just got xochitl working using the client shim. The client in my fork will now detect if it's running in xochitl and use inline hooking to send updates to the rm2-framebuffer server.
So I think the cleanest way for this to work now is one systemd service that starts the server with remarkable-shutdown and then another service starts any launcher with the client shim. Starting apps from the launcher will inherit the client and just work.
I just got xochitl working using the client shim. The client in my fork will now detect if it's running in xochitl and use inline hooking to send updates to the rm2-framebuffer server.
So I think the cleanest way for this to work now is one systemd service that starts the server with remarkable-shutdown and then another service starts any launcher with the client shim. Starting apps from the launcher will inherit the client and just work.
I just pushed a new version of Oxide with rM2 input support. You could test with it https://github.com/Eeems/oxide/releases/tag/v2.0.1-beta. Although long press actions don't have an alternative yet. From what @Witos was telling me, there is still an issue with saving/recalling the screen via the methods that Oxide uses.
I just got xochitl working using the client shim. The client in my fork will now detect if it's running in xochitl and use inline hooking to send updates to the rm2-framebuffer server.
awesome!
So I think the cleanest way for this to work now is one systemd service that starts the server with remarkable-shutdown and then another service starts any launcher with the client shim. Starting apps from the launcher will inherit the client and just work.
seems reasonable. i wonder if it would be fine to have rm2fb do nothing if its on rM1 and edit the launcher packages to always use the rm2fb shim. i think the ultimate end goal is to have using rm2fb be transparent and unknown to end users, they just install a launcher and rm2fb and it's server/client shims get setup automatically.
one major piece for rm2fb is figuring out how to only have one SWTCON running on the system. currently, xochitl and rm2fb each have their own SWTCON which can lead to problems if they are both active at the same time.
this task is to figure out how to use xochitl's SWTCON for rendering or to make xochitl use rm2fb's SWTCON.
this is currently blocking multi-tasking launchers from working correctly since xochitl has to be stopped/started whenever rm2fb is running.