Multitasking

[Silent-Hunter]

So my question is, basically, how hard will it be to switch between a game and a chat application such as Telegram, or the Pyra's SMS application when it gets one? Or to answer a phone call while a game is running?

I'm thinking I might be playing SNES or something, and hear that I have a new message. I don't wanna lose my place in the game to answer it.

 

[elw3]

I suggest we could set up the phone software on a different tty, a quick test shows that switching the tty even sets the non shown programs into pause mode. Perfect for gaming.

 

[Silent-Hunter]

I suggest we could set up the phone software on a different tty, a quick test shows that switching the tty even sets the non shown programs into pause mode. Perfect for gaming.

Oh? What would that look like from a user standpoint? My only experience with changing TTY is when I switch from TTY1 to TTY2 on my laptop, with Ctrl+Alt+F1 and F2.

 

[tigerroast]

I suggest we could set up the phone software on a different tty, a quick test shows that switching the tty even sets the non shown programs into pause mode. Perfect for gaming.

Absolutely horrendous for online play. Presumably, that's a configurable option. It would be nice to have a small notification box from which to ascertain who's calling you and choose to answer/decline/silence the call.

To be fair, idk how much online gaming one would be doing within PyraOS. Doom, perhaps Phantasy Star Online 1+2 on Dreamcast, Vanquish, Street Fighter 2 CE, Streets of Rage 2 (apparently), and I can't think of much else.

 

[elw3]

Excuse me but what has a notification box to do with switching software? Do you even know what we discuss here?
You can get all the notification you want but in the end the question is what is going to happen to the running program if we decide to take the call.
So when it rings you either:
-close/pause your game of mario
-keep it running and have you phone partner listening to mario
-separate all phone stuff from the desktop stuff, ttys do that

 

[sulu]

A pretty simple way to stop and continue processes would be to send them the respective interrupt signals. It's essentially the same that happens if you call a program via a terminal, pause it with Ctrl+Z and resume it with the fg command.

For example, to stop a process, one could send it the SIGSTOP signal:

kill -19 <pid>

...and resume the process with SIGCONT:

kill -18 <pid>

This should work pretty well in most situations. However, some programs seem to be unimpressed by SIGSTOP. One such program is ketm [1], which apparently stops (the GUI freezes) after receiving SIGSTOP, but after receiving SIGCONT, it doesn't resume where it was stopped, but where it should be, had it run the entire time.
Without having studied the source code, I can only guess, that it uses an absolute counter for time progress that is bound to the system clock. I'd consider this bad programming, and there's nothing that can be done about that, except for fixing each affected program individually.
Hedgewars [2] on the other hand, works as expected.


[1] https://packages.debian.org/jessie/ketm
[2] https://packages.debian.org/jessie/hedgewars

 

[Silent-Hunter]

A pretty simple way to stop and continue processes would be to send them the respective interrupt signals. It's essentially the same that happens if you call a program via a terminal, pause it with Ctrl+Z and resume it with the fg command.

For example, to stop a process, one could send it the SIGSTOP signal:

kill -19 <pid>

...and resume the process with SIGCONT:

kill -18 <pid>

This should work pretty well in most situations. However, some programs seem to be unimpressed by SIGSTOP. One such program is ketm [1], which apparently stops (the GUI freezes) after receiving SIGSTOP, but after receiving SIGCONT, it doesn't resume where it was stopped, but where it should be, had it run the entire time.
Without having studied the source code, I can only guess, that it uses an absolute counter for time progress that is bound to the system clock. I'd consider this bad programming, and there's nothing that can be done about that, except for fixing each affected program individually.
Hedgewars [2] on the other hand, works as expected.


[1] https://packages.debian.org/jessie/ketm
[2] https://packages.debian.org/jessie/hedgewars

I tried this with Links, and it works pretty well.

But what I'm referring to is how on the Pandora, when you're running a fullscreen emulator, even if you pause it you can't switch workspaces or programs. You have to quit the emulator.

 

[sulu]

I have no Pandora. Therefore I'm not familiar with the Linux distro it's running. And I'm not very familiar with emulators either.

To switch the focus from one program to another in an X session running a window manager (WM), the programs need to allow the WM to control the program window in the first place. This is usually the case, but not always.

Assuming your emulator allows this, then the problem is most likely that it grabs the keyboard, so all inputs are routed into the emulator. You're trapped in it. Usually, programs that grab the keyboard have some "magic" key combination that allows you to break out of the application (Ctrl+F10 in dosbox, the "Host" key in virtualbox), to send keyboard commands to the hosting WM. These magic key combinations can be scripted, for example via xdotool, but this tends to be unreliable. The window manager can also be controlled directly, for example via wmctrl. Some popup could be displayed that lets you decide, whether you want to leave the emulator or not.

If the emulator doesn't allow the WM to control it, then Elw3's idea should still provide a solution. If you start two independent X servers on two different TTYs, one for the emulator, the other for the phone software, then an incoming call can still switch from one X server to the other via the chvt command. This command however needs root privileges, so one needs to be careful when programming this, as it is potentially vulnerable to privilege escalations.
This method has the drawback though, that it doesn't allow for any user interaction. It will force you to the other X server without you knowing if you're even interested in this call.

 

[slaeshjag]

A thing a few of the emulators does on the pandora, is to directly take control over /dev/fb1 and overlay it over any framebuffer that the X server is using, which switching tty does not affect. Such emulators would need to be aware of focus switching and turn off that overlay.

 

[tigerroast]

Excuse me but what has a notification box to do with switching software?

Being able to accept/decline calls without having the call disrupt what I'm doing? I don't want my apps to pause when the Pyra is called, full stop. My phone doesn't even do that. I want to replicate the behavior AND have the benefit of PyraOS' multi-tasking capabilities.

Do you even know what we discuss here?

Have you ever used a phone?

You can get all the notification you want but in the end the question is what is going to happen to the running program if we decide to take the call.

Hopefully it keeps running and I don't get the steering wheel snatched from my hands. Or, at the very least, I can set it to do just that.

So when it rings you either:
-close/pause your game of mario
-keep it running and have you phone partner listening to mario
-separate all phone stuff from the desktop stuff, ttys do that

The false dichotomy has evolved into the false trichotomy! First, my problem is that I don't want to stop what I'm doing to answer the phone. I don't do it now, I won't do it then. The Pyra will give me the power to use it how I want to. Item #1 in your list is likely not gonna happen.

Item #2 makes no damn sense. On my Galaxy S5A, since all audio coming from MY side of the call comes from the microphone, I can still listen to YouTube or SoundCloud while talking and the other person won't hear a damn thing from those apps. They'll only hear me and whatever background noise. Why should that be any different on PyraOS? Just play Mario and only allow audio from the mic to be sent to the other person. Also, I don't have to stop what I'm doing just to view someone's text; the contents of said text is readable from the notification area on top of the screen. Obviously, this will be different and can be changed on the Pyra, but something similar isn't out of the question, nor should it be.

As for Item #3, your suggestion could be one solution, that I'm not denying. That doesn't mean, however, that there doesn't exist another method. Rather than separate the phone software, incorporate it into the desktop environment such that all behavior is well-defined and configurable. Thanks to our lord and savior systemd, it could be as simple as running a daemon to listen in on the LTE module for calls/texts, get systemd to start/wake the phone software in the form of a small box/window, and having that window give you the option to answer/decline/silence the call (answering the call putting the program in the background as well and not over the program in use). No need for tty switching that will put the brakes on what I'm doing.

 

[levi]

My phone switches context back to the phone app when I receive a call, backgrounding any apps (which usually causes them to pause, if that makes sense).

I'm not completely sure how holding down the Pandora button works on a LCD enabled unit, but on my TV out unit it brings up the toolbar over the framebuffer, and you can alt-tab back into the game program afterwards. A lot of games don't like being fiddled with like that though, but it might be worth investigating how that works.

 

[Askarus]

A thing a few of the emulators does on the pandora, is to directly take control over /dev/fb1 and overlay it over any framebuffer that the X server is using, which switching tty does not affect. Such emulators would need to be aware of focus switching and turn off that overlay.

AFAIK the Pandora has 2 layers. The default one and the framebuffer uses you mentioned.
The OMAP5 has 3 layers so one could be used for such notifications and/or a global settings menu like Android does.

I've read that somewhere here some time ago but I'm not 100% sure.

 

[elw3]

I think the pandora also has 3, notas sys info tool runs there if i remember correctly.

 

[Yoyobuae]

My phone switches context back to the phone app when I receive a call, backgrounding any apps (which usually causes them to pause, if that makes sense).

That's because in Android and iOS the apps are designed to be like that. Because Google/Apple mandate that apps need to be ready to be paused/stopped at any time, and then later be resumed/restarted. It's up to the app creator to take the necessary precautions to ensure the app continues back where it was when it was interrupted.

 

[levi]

Yes, and that could be the same in the Pyra's OS, or we could make use of signals to do the pausing stuff for us. I was mainly responding to tigerroasts claim he has a phone that continues to play music while he's trying to take a call, which just sounds odd to me, and not what I'd want from my Pyra.

FWIW, my phone doesn't run Android or iOS. I believe this behaviour was common even before those came around.

 

[tigerroast]

Yes, and that could be the same in the Pyra's OS, or we could make use of signals to do the pausing stuff for us. I was mainly responding to tigerroasts claim he has a phone that continues to play music while he's trying to take a call, which just sounds odd to me, and not what I'd want from my Pyra.

With a Galaxy S5, I can set the phone to display a call notification pop-up rather than close/completely obscure the app through the settings. If I'm on SoundCloud or any other app when I'm called, I can still use the app, even after I answer the call. Of course, the music is dimmed and the ringtone takes over, and the call volume will remain at a higher volume than the music volume no matter what. However, SoundCloud never stops streaming the music, even when the ringtone takes over and I can no longer hear the music.

That is what I want to replicate on the Pyra. Just substitute music for whatever else. Games, browsing, typing, laundering Bitcoin, hacking into DNC email servers, what-have-you. Something you don't want to stop doing unless it's your boss or the FBI calling.

 

[Silent-Hunter]

Yes, and that could be the same in the Pyra's OS, or we could make use of signals to do the pausing stuff for us. I was mainly responding to tigerroasts claim he has a phone that continues to play music while he's trying to take a call, which just sounds odd to me, and not what I'd want from my Pyra.

FWIW, my phone doesn't run Android or iOS. I believe this behaviour was common even before those came around.

What does your phone run?

 

[zmatt]

AFAIK the Pandora has 2 layers. The default one and the framebuffer uses you mentioned.
The OMAP5 has 3 layers so one could be used for such notifications and/or a global settings menu like Android does.

OMAP3 has 3 layers, OMAP5 has 4.

You only need those to show four buffers at the same time (three of which support scaling and color space transformation), with individual placement on the display, z-order, and alpha compositing. By default one layer is used, attached to the buffer belonging to /dev/fb0, but you can happily detach it without the application using it even realizing it's now drawing in an off-screen buffer. Or you can use one of the other layers for an overlay.

 

[levi]

What does your phone run?

It's an old Symbian smartphone.

 

[Silent-Hunter]

It's an old Symbian smartphone.

Oh! I like those.