integrate against xochitl

[raisjn]

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.

[raisjn]

some ideas:

• what happens if xochitl and rm2fb use same shared memory for framebuffer? does it allow two SWTCON to exist or is more bookkeeping happening internally inside SWTCON that needs to be shared?
• have xochitl use rm2fb to display: take over pthread_create and prevent generator/vsync threads from activating, then have own thread that sends updates to rm2fb server
• use xochitl as the rm2fb server process: this would require extra work to allow pausing xochitl
• use xochitl from rM1 with client shim

[antartica]

Proposal for integrating rm2fb with xochitl:

• The idea is having only one SWTCON process (xochitl).
• As xochitl is closed source and modifying the GUI thread there is difficult, my proposal is doing the modifications deeper in the stack, that is, inside the qtcore library.
• The modifications would be done in the Qt sources so that the main loop of the GUI thread of qt has additional functionality to communicate with rm2fb, and has the capability to block the UI messages when rm2fb is in active use. Disclaimer: I have not hacked the qt sources in the past so not sure if this is easy or not.
• After compiling a modified qtcore, LD_PRELOAD that qtcore when launching xochitl (the original qtcore on disk would be left untouched).
• That xochitl would provide the SWTCON to rm2fb. In other words: instead of launching another SWTCON and pausing xochitl, we block all messages from reaching xochitl GUI main loop but with the rest of the xochiltl threads running, so that it is possible to use xochitl as the server.

Implementing this would be in two phases:

1. check that it is possible to compile qt 5.11.3+gitAUTOINC+08de243eaa-r0 for the remarkable and that xochitl works with that newly compiled qtcore library.
2. Modify the sources of the main loop of qtcore (probably QApplication or QEventloop) to integrate the necessary communication bits of rm2fb.

[raisjn]

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

[raisjn]

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

[timower]

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.

[Eeems]

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.

[raisjn]

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.