Use SIGSTOP instead of killing xochitl?

[Pegasis]

Hi, this library looks awsome! My remarkable 2 is comming this October and I can't wait writing code for it (hope all the apis are the same so this lib will still work)

As far as I'm aware of, all the apps written for remarkable requires killing xochitl then restarting it when the app exits, which is slow.

I'm thinking about can we send SIGSTOP to pause xochitl instead of killing it, and send SIGCONT to it when the app exits.

Since xochitl is paused so the last frame is still on the screen, we can even create overlay on top of the original xochitl ui. (That will be super cool!)

I can't test these thoughts since I don't have the device yet, I'm wondering can someone test this approach and see how it turns out?

[Volker Mische]

I just tried. The problem is that it still receives events. Example: I SIGSTOPed xochitl, then ran the demo app and touched somewhere. Then terminated the demo app and SIGCONTed xochitl again. Now it opened the document that was where I touched.

[Pegasis]

After some googling I found a way to stop other programs from recieving input events: EVIOCGRAB. I just wrote a test program rm_grab_input_test.

If you run it like ./rm_grab /dev/input/event1 3, theoretically xochitl won't be able to recieve touchscreen events even if its running, and rm_grab will print input events in the terminal.

rm_grab will quit after 3 seconds and everything should return to normal.

[Pegasis]

@okayzed Wow amazing job there! (btw why not put it on Awesome reMarkable so more people can find it (Ok I just saw your forked repo))

I was thinking about the same thing:

1. Make a rule that only launcher can grab input devices.
2. Launcher is responsible for pausing and resuming applications.
3. If an app needs to run in the background, create a seperate systemd service and communicate with it using things like a unix socket.
4. Make an api so a background process can launch the launcher or other apps.

---

We created reMarkable to help you focus

reMarkable devs will be so mad at what we are doing here 😂

[Nathaniel van Diepen]

@PegasisForever I've basically implemented a single application grabbing all button presses and only sending through what it doesn't care about:
https://github.com/Eeems/oxidize/blob/master/applications/button-capture/main.cpp#L149-L162
https://github.com/Eeems/oxidize/blob/master/applications/button-capture/main.cpp#L84-L96

Not a perfect solution, but it does work.

[Linus K.]

I think this issue can be closed. @Eeems and @raisjn / @okayzed launchers (Oxide and reMux respectivly) do this very thing and are application agnostic. So when using this library you can create an app that integrates a .draft file into /etc/draft or even better /opt/etc/draft and create a toltec package.

Then installing your simple app will be as easy as running opkg install your_app and it'll be available in all current launchers for the reMarkable. Though only reMux and Oxide will actually be able to run multiple applications at the same time by freezing others. The libremarkable app doesn't need to care about that (even though at least Oxide has a api around apps called rot you can use).

In the future we may want to add support with @Eeems' app ecosystem to get more features and make the app aware if the user has started it using Oxide. This will be an entirely new topic though.

[Nathaniel van Diepen]

Technically rot is just an interface into the API that users can use. It's actually a DBUS api that can be directly called by any app.