Yes, I am old school and like to work on a TTY whenever possible. But of
course I need GUI browsers and other GUI stuff too.

And before someone says, "Use Xterm in full screen", please don't. :-)

My problem is that on MATE (MINT Linux) pretty much everything stalls
once I switch to a TTY. That includes videos playing in a browser. They
continue at the same position when I return to X - so not rushing to the
time mark the video would be by now.

There are also no browser audio notifications when events happen.

Other than browser apps also stop. I just tested the MAME emulator.

The only app which to my surprise seems to work is Linphone; it rings
when someone calls, even when I am on a TTY.

So, is there a way to tell MATE (or MINT, or Debian it runs upon) to not
stop apps when leaving the GUI?
--
Andreas

https://news-commentaries.blogspot.com/

On 18/02/2023 07:07, Andreas Kohlbach wrote:
> So, is there a way to tell MATE (or MINT, or Debian it runs upon) to not
> stop apps when leaving the GUI?

I very much doubt it.
You are essentially suspending the GUI (IIRC) when invoking a full
screen TTY, which is why we all use a terminal application, or in fact
several of them, when we want to 'go Gui-less'

--
Climate Change: Socialism wearing a lab coat.

Andreas Kohlbach <ank@spamfence.net> wrote:
> Yes, I am old school and like to work on a TTY whenever possible. But of
> course I need GUI browsers and other GUI stuff too.
>
> And before someone says, "Use Xterm in full screen", please don't. :-)
>
> My problem is that on MATE (MINT Linux) pretty much everything stalls
> once I switch to a TTY.

If you mean the shift+alt+Fx key to swtich to one of Linux's native
terminals, then this is expected. The switch out of X and back to a
TTY is a suspend of X, meaning the entire X session is paused.

> That includes videos playing in a browser. They continue at the same
> position when I return to X - so not rushing to the time mark the
> video would be by now.

Because switching to the TTY stopped X from running anything until you
switched back. It is similar to when you hit ctrl+z from a shell to
suspend a running forground task and that task is suspended. It also
stops running.

> The only app which to my surprise seems to work is Linphone; it rings
> when someone calls, even when I am on a TTY.

Most likely it launches a non-X background task to monitor for incoming
calls and generate the ring sound.

> So, is there a way to tell MATE (or MINT, or Debian it runs upon) to not
> stop apps when leaving the GUI?

No, not by switching back to a TTY. You are getting exactly what you
are asking for when you do so, a suspension of all of Xwindows.

The simplest and best way for you to keep the the rest of the gui
running while using a terminal is to just launch an xterm (or rxvt or
whatever your favorite terminal emulator is). That way you have a
"tty" and the rest of the X GUI session continues without being
stopped. Whether these xterms are windowed or full screen is
immaterial.

If you insist on only using the native TTY's, then you could jury-rig
something with a headless X server that you VNC connect to from a real
X server. Then, when you switch away from the real X server, the VNC
connection will be paused, but the rest of the headless server should
continue to run.

On 2023-02-18 15:59, Rich wrote:
> Andreas Kohlbach <ank@spamfence.net> wrote:
>> Yes, I am old school and like to work on a TTY whenever possible. But of
>> course I need GUI browsers and other GUI stuff too.
>>
>> And before someone says, "Use Xterm in full screen", please don't. :-)
>>
>> My problem is that on MATE (MINT Linux) pretty much everything stalls
>> once I switch to a TTY.
>
> If you mean the shift+alt+Fx key to swtich to one of Linux's native
> terminals, then this is expected. The switch out of X and back to a
> TTY is a suspend of X, meaning the entire X session is paused.

AFAIK the GUI is not suspended. This behaviour is relatively new, I
don't remember when it started. It affects multimedia.

You can run a long job, like a backup script, and it
should continue running non stop when switching to a TTY.

The same toolset that is used to "detect who is at the seat" does it.
Rationale is that it gives permissions to use the sound device to the
person that is seated, meaning the person having the GUI. As when in tty
mode no one has the GUI, there is no permission to use sound and things
stop.

This could be HAL/ConsoleKit/PolicyKit. Or could be the display manager
doing it.

The way to avoid this is not using the TTY, but an xterm.

--
Cheers, Carlos.

On Sat, 18 Feb 2023 10:02:56 +0000, The Natural Philosopher wrote:
>
> On 18/02/2023 07:07, Andreas Kohlbach wrote:
>> So, is there a way to tell MATE (or MINT, or Debian it runs upon) to not
>> stop apps when leaving the GUI?
>
> I very much doubt it.
> You are essentially suspending the GUI (IIRC) when invoking a full
> screen TTY, which is why we all use a terminal application, or in fact
> several of them, when we want to 'go Gui-less'

Why would it suspend the GUI? It's not like you suspend a TTY when
switching to the GUI.

Besides the GUI did not get suspended on my last installation eons
ago. Thus something in the inner workings might have changed. And
probably something I cannot do anything about.

But I hoped there was something to get around, so I asked.
--
Andreas

On Sat, 18 Feb 2023 17:59:06 +0100, Carlos E.R. wrote:
>
> On 2023-02-18 15:59, Rich wrote:
>> Andreas Kohlbach <ank@spamfence.net> wrote:
>>> Yes, I am old school and like to work on a TTY whenever possible. But of
>>> course I need GUI browsers and other GUI stuff too.
>>>
>>> And before someone says, "Use Xterm in full screen", please don't. :-)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [1]
>>> My problem is that on MATE (MINT Linux) pretty much everything stalls
>>> once I switch to a TTY.
>> If you mean the shift+alt+Fx key to swtich to one of Linux's native
>> terminals, then this is expected. The switch out of X and back to a
>> TTY is a suspend of X, meaning the entire X session is paused.
>
> AFAIK the GUI is not suspended. This behaviour is relatively new, I
> don't remember when it started. It affects multimedia.

Thanks Carlos. Something I also observed: new thingy. Probably five years
or less.

> You can run a long job, like a backup script, and it
> should continue running non stop when switching to a TTY.
>
> The same toolset that is used to "detect who is at the seat" does
> it. Rationale is that it gives permissions to use the sound device to
> the person that is seated, meaning the person having the GUI. As when
> in tty mode no one has the GUI, there is no permission to use sound
> and things stop.

Ah "seats". I noted this term in logs. Will have to read up on this. Thanks.

> This could be HAL/ConsoleKit/PolicyKit. Or could be the display
> manager doing it.

Sounds promising.

But hard to google for "GUI" and "suspend", as results usually deal with
suspending the whole system (hibernate).

[1]

> The way to avoid this is not using the TTY, but an xterm.

That I tried to avoid. I want to kick it old school. :-D

[Update]

New observation: Just started a video via mpv and switched to a TTY (to
write this article here). I still can hear the music playing! Assuming
the video would also progress.

So some stuff seems to "bypass a 'suspended' GUI". Now I'd like to tell
that a suspension doesn't happen at all, or tell more apps to get around
this.
--
Andreas

On 2023-02-18 20:35, Andreas Kohlbach wrote:
> On Sat, 18 Feb 2023 17:59:06 +0100, Carlos E.R. wrote:
>> On 2023-02-18 15:59, Rich wrote:
>>> Andreas Kohlbach <ank@spamfence.net> wrote:
>>>> Yes, I am old school and like to work on a TTY whenever possible. But of
>>>> course I need GUI browsers and other GUI stuff too.
>>>>
>>>> And before someone says, "Use Xterm in full screen", please don't. :-)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [1]

Yes, I had seen that and purposely ignored it :-P

>>>> My problem is that on MATE (MINT Linux) pretty much everything stalls
>>>> once I switch to a TTY.
>>> If you mean the shift+alt+Fx key to swtich to one of Linux's native
>>> terminals, then this is expected. The switch out of X and back to a
>>> TTY is a suspend of X, meaning the entire X session is paused.
>>
>> AFAIK the GUI is not suspended. This behaviour is relatively new, I
>> don't remember when it started. It affects multimedia.
>
> Thanks Carlos. Something I also observed: new thingy. Probably five years
> or less.
>
>> You can run a long job, like a backup script, and it
>> should continue running non stop when switching to a TTY.
>>
>> The same toolset that is used to "detect who is at the seat" does
>> it. Rationale is that it gives permissions to use the sound device to
>> the person that is seated, meaning the person having the GUI. As when
>> in tty mode no one has the GUI, there is no permission to use sound
>> and things stop.
>
> Ah "seats". I noted this term in logs. Will have to read up on this. Thanks.
>
>> This could be HAL/ConsoleKit/PolicyKit. Or could be the display
>> manager doing it.
>
> Sounds promising.
>
> But hard to google for "GUI" and "suspend", as results usually deal with
> suspending the whole system (hibernate).

I have no idea if systemd can be involved, I forgot to mention.

>
> [1]
>
>> The way to avoid this is not using the TTY, but an xterm.
>
> That I tried to avoid. I want to kick it old school. :-D
>
> [Update]
>
> New observation: Just started a video via mpv and switched to a TTY (to
> write this article here). I still can hear the music playing! Assuming
> the video would also progress.

Well, the player should be clever and skip the displaying part ;-)

Also if you just minimize the player. Why do all the job of rendering
the video?

The speculation how much to decode and at what level stop processing
video, can be "big". At worst, all the decoding is done but just stops
at the video memory move.

> So some stuff seems to "bypass a 'suspended' GUI". Now I'd like to tell
> that a suspension doesn't happen at all, or tell more apps to get around
> this.

--
Cheers, Carlos.

"Carlos E.R." <robin_listas@es.invalid> writes:

> On 2023-02-18 15:59, Rich wrote:
>> Andreas Kohlbach <ank@spamfence.net> wrote:
>>> Yes, I am old school and like to work on a TTY whenever possible. But of
>>> course I need GUI browsers and other GUI stuff too.
>>>
>>> And before someone says, "Use Xterm in full screen", please don't. :-)
>>>
>>> My problem is that on MATE (MINT Linux) pretty much everything stalls
>>> once I switch to a TTY.
>> If you mean the shift+alt+Fx key to swtich to one of Linux's native
>> terminals, then this is expected. The switch out of X and back to a
>> TTY is a suspend of X, meaning the entire X session is paused.
>
> AFAIK the GUI is not suspended. This behaviour is relatively new, I
> don't remember when it started. It affects multimedia.
>
> You can run a long job, like a backup script, and it
> should continue running non stop when switching to a TTY.
>
> The same toolset that is used to "detect who is at the seat" does
> it. Rationale is that it gives permissions to use the sound device to
> the person that is seated, meaning the person having the GUI. As when
> in tty mode no one has the GUI, there is no permission to use sound
> and things stop.
>
> This could be HAL/ConsoleKit/PolicyKit. Or could be the display
> manager doing it.

I did:

journalctl -f

I got this when switching to a TTY:

pipewire[1514]: spa.alsa: hw:0,7: Channels doesn't match (requested 8, got 2)

Looks to me like something is redirecting sound production.

> The way to avoid this is not using the TTY, but an xterm.

Agree. A terminal session is better than a TTY is so many ways.

--
Dan Espen

On 18/02/2023 at 17.59, Carlos E.R. wrote:
> AFAIK the GUI is not suspended. This behaviour is relatively new, I
> don't remember when it started. It affects multimedia.
>
> You can run a long job, like a backup script, and it
> should continue running non stop when switching to a TTY.
>
> The same toolset that is used to "detect who is at the seat" does it.
> Rationale is that it gives permissions to use the sound device to the
> person that is seated, meaning the person having the GUI. As when in tty
> mode no one has the GUI, there is no permission to use sound and things
> stop.
>
> This could be HAL/ConsoleKit/PolicyKit. Or could be the display manager
> doing it.
>
> The way to avoid this is not using the TTY, but an xterm.

Or perhaps adding your username to 'audio' group.

--
mrg

On Sat, 18 Feb 2023 21:00:22 +0100, Carlos E.R. wrote:
>
> On 2023-02-18 20:35, Andreas Kohlbach wrote:
>> On Sat, 18 Feb 2023 17:59:06 +0100, Carlos E.R. wrote:
>>
>>> The way to avoid this is not using the TTY, but an xterm.
>> That I tried to avoid. I want to kick it old school. :-D
>> [Update]
>> New observation: Just started a video via mpv and switched to a TTY
>> (to
>> write this article here). I still can hear the music playing! Assuming
>> the video would also progress.
>
> Well, the player should be clever and skip the displaying part ;-)

It started with rendering the video on the GUI. Switching to the TTY
sound was still there. Unfortunately Schroedinger's Cat doesn't allow you
to know if the video is also still playing while you not look at it. :-)

> Also if you just minimize the player. Why do all the job of rendering
> the video?

Just checked. It doesn't matter if the player is full screen or windowed.

> The speculation how much to decode and at what level stop processing
> video, can be "big". At worst, all the decoding is done but just stops
> at the video memory move.

As mentioned there is at least one other app too. Linphone still rings
when I was called but at the TTY.

I just notice that Linphone also has a curses based interface. Something I
should look into.
--
Andreas

On Sat, 18 Feb 2023 20:08:26 -0500, Dan Espen wrote:
>
> "Carlos E.R." <robin_listas@es.invalid> writes:

[...]

>> This could be HAL/ConsoleKit/PolicyKit. Or could be the display
>> manager doing it.
>
> I did:
>
> journalctl -f
>
> I got this when switching to a TTY:
>
> pipewire[1514]: spa.alsa: hw:0,7: Channels doesn't match (requested 8, got 2)
>
> Looks to me like something is redirecting sound production.

Not entries here. Also none is /var/log/syslog (which looks very similar
to the journalctl output otherwise).

>> The way to avoid this is not using the TTY, but an xterm.
>
> Agree. A terminal session is better than a TTY is so many ways.

Well, if I only needed text base stuff I could not run X at all. OK, then
there is not problem with suspending stuff, as X doesn't exist.

In fact on the old computer I demoted to a server, I removed X, which
removed most if not all of all X related stuff (Firefox as one example),
freeing 20 GB or more. I could still use it to write in the usenet,
mails or use text browsers.

May be this is because when I first got Linux in the mid/late 90s there
was not enough space on the hard disk (most occupied by Windows 95) to
also install X11. Thus I learned to use Linux with the command line
only. Call it nostalgia. :-D
--
Andreas

Andreas Kohlbach <ank@spamfence.net> writes:

> On Sat, 18 Feb 2023 20:08:26 -0500, Dan Espen wrote:
>>
>> "Carlos E.R." <robin_listas@es.invalid> writes:
>
> [...]
>
>>> This could be HAL/ConsoleKit/PolicyKit. Or could be the display
>>> manager doing it.
>>
>> I did:
>>
>> journalctl -f
>>
>> I got this when switching to a TTY:
>>
>> pipewire[1514]: spa.alsa: hw:0,7: Channels doesn't match (requested 8, got 2)
>>
>> Looks to me like something is redirecting sound production.
>
> Not entries here. Also none is /var/log/syslog (which looks very similar
> to the journalctl output otherwise).
>
>>> The way to avoid this is not using the TTY, but an xterm.
>>
>> Agree. A terminal session is better than a TTY is so many ways.
>
> Well, if I only needed text base stuff I could not run X at all. OK, then
> there is not problem with suspending stuff, as X doesn't exist.
>
> In fact on the old computer I demoted to a server, I removed X, which
> removed most if not all of all X related stuff (Firefox as one example),
> freeing 20 GB or more. I could still use it to write in the usenet,
> mails or use text browsers.
>
> May be this is because when I first got Linux in the mid/late 90s there
> was not enough space on the hard disk (most occupied by Windows 95) to
> also install X11. Thus I learned to use Linux with the command line
> only. Call it nostalgia. :-D

I learned Unix on a HP2641 tty. It could draw line drawing characters
so I had Emacs display a cute ruler at the top of the screen.

Now my ttys have these very attractive stippled backgrounds and
colorized prompts. They can be any size I need. I can make the font
any size I need. I don't have to put the directory in the prompt
because it's in the WM title bar.

I'm not working up any nostalgia.

--
Dan Espen

Dan Espen <dan1espen@gmail.com> writes:

> "Carlos E.R." <robin_listas@es.invalid> writes:
>
>> On 2023-02-18 15:59, Rich wrote:
>>> Andreas Kohlbach <ank@spamfence.net> wrote:
>>>> Yes, I am old school and like to work on a TTY whenever possible. But of
>>>> course I need GUI browsers and other GUI stuff too.
>>>>
>>>> And before someone says, "Use Xterm in full screen", please don't. :-)
>>>>
>>>> My problem is that on MATE (MINT Linux) pretty much everything stalls
>>>> once I switch to a TTY.
>>> If you mean the shift+alt+Fx key to swtich to one of Linux's native
>>> terminals, then this is expected. The switch out of X and back to a
>>> TTY is a suspend of X, meaning the entire X session is paused.
>>
>> AFAIK the GUI is not suspended. This behaviour is relatively new, I
>> don't remember when it started. It affects multimedia.
>>
>> You can run a long job, like a backup script, and it
>> should continue running non stop when switching to a TTY.
>>
>> The same toolset that is used to "detect who is at the seat" does
>> it. Rationale is that it gives permissions to use the sound device to
>> the person that is seated, meaning the person having the GUI. As when
>> in tty mode no one has the GUI, there is no permission to use sound
>> and things stop.
>>
>> This could be HAL/ConsoleKit/PolicyKit. Or could be the display
>> manager doing it.
>
> I did:
>
> journalctl -f
>
> I got this when switching to a TTY:
>
> pipewire[1514]: spa.alsa: hw:0,7: Channels doesn't match (requested 8, got 2)
>
> Looks to me like something is redirecting sound production.

In this test where I lost audio I switched to a TTY with root signed in.
I just switched to another TTY. At the password prompt, the audio stopped.
After I signed in as the same user, the audio came back on. So, works for me.

--
Dan Espen

On 18/02/2023 19:35, Andreas Kohlbach wrote:
> On Sat, 18 Feb 2023 17:59:06 +0100, Carlos E.R. wrote:
>>
>> On 2023-02-18 15:59, Rich wrote:
>>> Andreas Kohlbach <ank@spamfence.net> wrote:
>>>> Yes, I am old school and like to work on a TTY whenever possible. But of
>>>> course I need GUI browsers and other GUI stuff too.
>>>>
>>>> And before someone says, "Use Xterm in full screen", please don't. :-)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [1]
>>>> My problem is that on MATE (MINT Linux) pretty much everything stalls
>>>> once I switch to a TTY.
>>> If you mean the shift+alt+Fx key to swtich to one of Linux's native
>>> terminals, then this is expected. The switch out of X and back to a
>>> TTY is a suspend of X, meaning the entire X session is paused.
>>
>> AFAIK the GUI is not suspended. This behaviour is relatively new, I
>> don't remember when it started. It affects multimedia.
>
> Thanks Carlos. Something I also observed: new thingy. Probably five years
> or less.
>
>> You can run a long job, like a backup script, and it
>> should continue running non stop when switching to a TTY.
>>
>> The same toolset that is used to "detect who is at the seat" does
>> it. Rationale is that it gives permissions to use the sound device to
>> the person that is seated, meaning the person having the GUI. As when
>> in tty mode no one has the GUI, there is no permission to use sound
>> and things stop.
>
> Ah "seats". I noted this term in logs. Will have to read up on this. Thanks.
>
>> This could be HAL/ConsoleKit/PolicyKit. Or could be the display
>> manager doing it.
>
> Sounds promising.
>
> But hard to google for "GUI" and "suspend", as results usually deal with
> suspending the whole system (hibernate).
>
> [1]
>
>> The way to avoid this is not using the TTY, but an xterm.
>
> That I tried to avoid. I want to kick it old school. :-D
>
> [Update]
>
> New observation: Just started a video via mpv and switched to a TTY (to
> write this article here). I still can hear the music playing! Assuming
> the video would also progress.
>
> So some stuff seems to "bypass a 'suspended' GUI". Now I'd like to tell
> that a suspension doesn't happen at all, or tell more apps to get around
> this.

I think what may happen is that video events directed to the GUI don't
get thrown away, but queued.

It is arguable as to what the best action is, if a tree falls in the GUI
and no one is there to watch it,

For sure stuff that doesn't need a GUI to work at all, like a command
line instruction to play a sound file, will carry on.

--
It’s easier to fool people than to convince them that they have been fooled.
Mark Twain

On 2023-02-19 02:08, Dan Espen wrote:
> "Carlos E.R." <robin_listas@es.invalid> writes:
>
>> On 2023-02-18 15:59, Rich wrote:
>>> Andreas Kohlbach <ank@spamfence.net> wrote:
>>>> Yes, I am old school and like to work on a TTY whenever possible. But of
>>>> course I need GUI browsers and other GUI stuff too.
>>>>
>>>> And before someone says, "Use Xterm in full screen", please don't. :-)
>>>>
>>>> My problem is that on MATE (MINT Linux) pretty much everything stalls
>>>> once I switch to a TTY.
>>> If you mean the shift+alt+Fx key to swtich to one of Linux's native
>>> terminals, then this is expected. The switch out of X and back to a
>>> TTY is a suspend of X, meaning the entire X session is paused.
>>
>> AFAIK the GUI is not suspended. This behaviour is relatively new, I
>> don't remember when it started. It affects multimedia.
>>
>> You can run a long job, like a backup script, and it
>> should continue running non stop when switching to a TTY.
>>
>> The same toolset that is used to "detect who is at the seat" does
>> it. Rationale is that it gives permissions to use the sound device to
>> the person that is seated, meaning the person having the GUI. As when
>> in tty mode no one has the GUI, there is no permission to use sound
>> and things stop.
>>
>> This could be HAL/ConsoleKit/PolicyKit. Or could be the display
>> manager doing it.
>
> I did:
>
> journalctl -f
>
> I got this when switching to a TTY:
>
> pipewire[1514]: spa.alsa: hw:0,7: Channels doesn't match (requested 8, got 2)
>
> Looks to me like something is redirecting sound production.

Yes. It (HAL/ConsoleKit/PolicyKit/DM) tries to give control of sound to
the TTY.

Ah, I see in another post that there is a difference when login with the
same user.

>
>> The way to avoid this is not using the TTY, but an xterm.
>
> Agree. A terminal session is better than a TTY is so many ways.

:-D

--
Cheers, Carlos.

On Sat, 18 Feb 2023 22:23:01 -0500, Dan Espen wrote:
>
> Dan Espen <dan1espen@gmail.com> writes:
>
>> I did:
>>
>> journalctl -f
>>
>> I got this when switching to a TTY:
>>
>> pipewire[1514]: spa.alsa: hw:0,7: Channels doesn't match (requested 8, got 2)
>>
>> Looks to me like something is redirecting sound production.
>
> In this test where I lost audio I switched to a TTY with root signed in.
> I just switched to another TTY. At the password prompt, the audio stopped.
> After I signed in as the same user, the audio came back on. So, works for me.

Observed the same. When switching to another user it (and not even the
original user when switching back) have sound. I have to re-login. Annoying.
--
Andreas