Integrate with remux

[torwag]

I like oxide for bringing me the desktop like environment I like remux for being rather non-invasive and enabling me to quickly switch between concurrent running apps. Why not getting the best of both worlds. Using oxide as a desktop environment to do settings, starting applications, etc. and use remux as the task-manager to switch between different apps. Ultimately, if remux could even get to the point of a split view (2 programs side by side) and oxide focuses on the ui experience, we would have a very interesting combination.

[Eeems]

What is currently blocking this is #13 and also providing an API for applications to interact with oxide.

[Eeems]

#13 is largely underway and I think initial work on integrating remux can be done.

[LinusCDE]

Ultimately, if remux could even get to the point of a split view (2 programs side by side) and oxide focuses on the ui experience, we would have a very interesting combination.

I doubt that this will ever be implemented. Every app basically gets the full raw framebuffer and does what it wants. While it may be possible, it would involve some serious hacks to do so (basically wrapping /dev/fb0 and emulating it as well as all input in /dev/input).

Remux currently does multitasking by freezing the processes and screenshotting the framebuffer in-between, was well as some amazing tricks to overflow the ev ring buffer to prevent captured button pressed when a process resumes.

I fully agree with the rest though.

[Eeems]

Ultimately, if remux could even get to the point of a split view (2 programs side by side) and oxide focuses on the ui experience, we would have a very interesting combination.

I doubt that this will ever be implemented. Every app basically gets the full raw framebuffer and does what it wants. While it may be possible, it would involve some serious hacks to do so (basically wrapping /dev/fb0 and emulating it as well as all input in /dev/input).

I'm not against exploring this in the future. I'm not even convinced that it would require emulating the framebuffer. It is more likely that the system service (tarnish) would have an API for providing shared memory for apps to write to as their "window" and handled updating the screen.

Remux currently does multitasking by freezing the processes and screenshotting the framebuffer in-between, was well as some amazing tricks to overflow the ev ring buffer to prevent captured button pressed when a process resumes.

So does tarnish. @raisjnn and I have been sharing a lot of information the last number of weeks.

[LinusCDE]

Cool. Though wouldn't tarnish not require the apps to specifically work with tarnish in order to have that support?

[Eeems]

Cool. Though wouldn't tarnish not require the apps to specifically work with tarnish in order to have that support?

Yes it would. So it would only work for applications that explicitly supported it.

We might also be able to take a framebuffer by running an application in a chroot. So we could potentially handle drawing on top of applications that don't support it and locking them in to fullscreen display.

Something to explore for a 3.0 release.

[Eeems]

@raisjnn Is there anything else you need from oxide in order to implement this?

[raisjn]

so remux will do the following:

• when a flag is passed to remux, it opens in oneshot mode (and does not run indefinitely like it usually does)
• when a flag is passed to remux, it uses rot to get the list of available applications and which are currently active. it needs the apps name and app id here only (and will use that app id to communicate with rot). if we want to calculate memory usage of the app, we will also need the app's binary.
• in oneshot mode, remux will display itself as a modal dialog over the current framebuffer
  • when an option is selected, remux will tell rot to switch to that app, then rot will restore that app's last framebuffer and restore the app
  • when an option is not selected, remux will tell rot that no option was selected, and rot will restore the original framebuffer and unpause the app. (remux can restore the original framebuffer here, if you want)
• remux will then exit

[Eeems]

Hmm, I think it might make more sense to have it running as a backgroundable application. We would need some sort of way to bring it into the foreground, or at least tell tarnish that it's in the foreground again. Tarnish already does handle juggling the framebuffers, but it captures it the moment it's told to pause, so you'd need to not be on the screen, or to be a backgroundable application that's just brought into the foreground to handle it properly.

The API provides for you the following that you could use:

• PID of an application.
• List of running applications.
• List of all possible applications.
• Pause/Resume an application.
• Icon of an application.
• Application name and display name etc.

[raisjn]

how will tarnish signal remux? remux will listen for SIGCONT and go into action when it is sent? so far, i think everything is fine

[Eeems]

Correct, if tarnish is the one that launched remux, it'll know that it's in the background and send a SIGUSR1 that will need to be acked back to Tarnish. Technically you don't really need to ack it back as Tarnish will be waiting for 1s and then just assume you resumed properly, but it keeps you from pausing things for 1s.

When Tarnish sends you a SIGUSR2 it also wants you to ack back before 1s and stop being "in the foreground", but if you fail to ack that one it'll send a SIGSTOP.

[raisjn]

i'll look into the SIGUSR stuff. i think the main thing is that some remux behavior needs to be changed when not in standalone mode. current list is:

• don't take copies of framebuffer or restore them
• don't listen for button presses or gestures (this doesn't really matter if its paused)
• show modal when SIGCONT/SIGUSR1 are sent
• stub out its current method of reading app info to call into rot
• add a layer that handles interacting with apps & procs, so that it calls to rot when applicable, otherwise does its own proc management

i will have remux run with a special flag to enable these behaviors and the flag will assume that its only used in specific circumstance of being run by tarnish and interacting with rot.

[Eeems]

don't listen for button presses or gestures (this doesn't really matter if its paused)

It does matter if you are registered as a backgroundable application, since you get the whole SIGUSR2 dance instead of a SIGSTOP. Which will still allow you to listen for some sort of start guesture where you can tell Tarnish to "activate" remux.

The only hook I provide right now for button presses for applications are long presses of buttons, but the only one not already used by something is long press of the power button.

[Eeems]

Everything is in place for remux to integrate (aside from better documentation). I'm going to leave this out of a milestone and leave it for someone else to implement.

[Eeems]

@torwag since you've closed https://github.com/rmkit-dev/rmkit/issues/7 are you also intending to close this?