pure (non-GUI) terminals after recent years' changes?

hazel · 08-19-2022, 09:23 AM

There's been a great deal of beefing about this change with the kernel team taking zero notice. There is a kernel patch which restores scrolling and I've tried it out, but it has a bug that causes panics when output is very fast and voluminous so I stopped using it.

dchmelik · 08-23-2022, 11:57 PM

Quote:

Originally Posted by rkelsen

[...]still present in the pure text console. If you want to use it, you can. The way to do it is by disabling the frame buffer on boot.

The only catch is that you have to use legacy booting with LILO, because you cannot disable the frame buffer if you use UEFI.

Could I still use three monitors in high graphics & text resolutions and display graphics on pure (non-X) terminals non-root or is SVGAlib the only option and outdated/broken?
        LILO later broke on my SSD/M2/NVME so could I use GRUB?

rkelsen · 08-24-2022, 01:07 AM

It should also work with GRUB in non-EFI mode.

Without using the frame buffer, you'll get 80 characters x 25 characters which is standard text mode. The resolution will be 640 pixels x 400 pixels. Yes, it is quite ugly on a 27" screen.

If you want high resolution text & graphics, then you have to use the frame buffer.

I'm not sure if text mode will work with multiple screens, but you could perhaps experiment with screen or tmux?

IMO, in your situation (and given your requirements) it'd probably make more sense for you to use X terminals. With the frame buffer you're already most of the way there anyway... X terminals would be able to be spread out over multiple monitors, you'd get the built in scrollback ability, and also have the ability to switch between them using ALT-TAB...

Quote:

Originally Posted by hazel

There's been a great deal of beefing about this change with the kernel team taking zero notice.

Probably because nobody has stepped up and/or volunteered to maintain it.

dchmelik · 08-28-2022, 03:09 AM

Quote:

Originally Posted by rkelsen

[...] Without using the frame buffer, you'll get 80 characters x 25 characters which is standard text mode. The resolution will be 640 pixels x 400 pixels. [...]

Not higher VESA modes?! :O

rkelsen · 08-28-2022, 07:07 AM

Quote:

Originally Posted by dchmelik

Not higher VESA modes?! :O

No, if you want to use VESA modes you have to use the frame buffer.

The standard text console is as described in my earlier post.

selfprogrammed · 09-16-2022, 08:13 AM

As you can see from the responses, there are some people that respond badly to any suggestion that NOT everyone is happy.
Repeating self-important viewpoints that were rejected in the original posting does nothing to resolve this problem for those who are affected.
The pretense to escape admitting that there is a problem, reveals how little consideration is given to those who are affected by this problem.
Please go away, haunt some other posting.

I will be running 4.4.261 for now. I cannot get 5.5 to be useful without more work than I can give it right now.
This is a problem, because 5.5 has a new Firefox that is useful for some sites that will not work correctly using the Firefox available for 4.4.
I will have to look into porting the new Firefox back to 4.4.

Getting 5.5.15 running will be postponed until I got time to address things like rewriting the console driver.
At such time that I have something that is useful, I will post it here.
Maybe December, maybe 2023.

I am not expecting that submitting any requests, or a patch, into the "system" will do any good.
Any such submission will go first to the person who did this, and they will have as their first instinct to fight to the death
against any suggestion to change what they did, back to what it was.

Being maintainer for the affected console driver would not fix this either. I have been there. What will happen is that
there will be a war for control. Someone higher up will try to sit-on you and require that you submit any plans to them for approval.
You would need to know who did this, and what position they have in the hierarchy. You will need support from someone else
who can fight at that level in the hierarchy. Unless there is an offer to reconsider what was done, this is the only
safe assumption to make. Otherwise, you can waste an enormous amount of time and effort thinking that you are going to change things.
The distinction in this case is that there is a person already in the system that is going to fight against
any plans to restore scroll-back to the console.
You should notice that I have not taken any steps to identify the person who did this, because I have no interest in
initiating a war where the best weapon is your position in the hierarchy (which is what happens in any war of opinions).

It is entirely different from taking over maintaining a driver that no one else
has taken any interest in.

This thread is about how to fix the scroll-back in the console driver.
I think that being suckered in to being maintainer for the thing will not achieve that, for the above reasons.
If you have personal issues to grind away at, please start your own thread, ... go away.

Right now I have a release date for one of my free programs approaching, a pile of bug reports to deal with, and some new features to finish.
That work will have to be done on a 4.4.261 system.

keithpeter · 09-17-2022, 04:57 AM

Quote:

Originally Posted by selfprogrammed

This is a problem, because 5.5 has a new Firefox that is useful for some sites that will not work correctly using the Firefox available for 4.4.

https://gist.github.com/ruario/9672798

I find Ruario's firefox-latest.sh script useful for repacking the binaries issued by Mozilla if that is any use. I use the ESR versions and the resulting packages work fine on Slackware 14.2 with its 4.4 series kernel.

LuckyCyborg · 09-17-2022, 05:20 AM

Meanwhile in the Open-Source Kingdom, someone named David Airlie says

Quote:

We'd like to move to CONFIG_VT=n as the console and vt subsystem have historically been a source of bugs but are also nasty places for locking etc. It also can be the cause of oops going missing when it takes out the panic path with locking bugs stopping other paths from completely processing the oops (like pstore or serial).
...
Once you think through all the paths and things you want supported, you realise the best user console is going to be one that supports emojis and non-Latin scripts. This probably means you want a lightweight wayland compositor running a fullscreen VTE based terminal. Working back from the consequences of this means you probably aren't going to want this in systemd, and it should be a separate development.

The other area discussed was around the requirements for a panic/emergency kernel console, likely called drmlog, this would just be something to output to the display whenever the kernel panics or during boot before the user console is loaded.

https://www.phoronix.com/news/LPC-20...s-Accelerators

Seems like that not so far in future, if you want to play with Linux console would mean to use a Wayland server running a full screen Terminal, or something similar.

Comments?

elcore · 09-17-2022, 07:13 AM

Quote:

Originally Posted by LuckyCyborg

Comments?

Hopefully, the BSD kernel will have the legacy VGA console, and will support X at that point.

hazel · 09-17-2022, 07:16 AM

Quote:

Originally Posted by elcore

Hopefully, the BSD kernel will have the legacy VGA console, and will support X at that point.

Would it actually be possible to build and use a BSD kernel within Linux? I know there is a version of Debian that uses the HURD kernel, so perhaps it's not outrageous.

LuckyCyborg · 09-17-2022, 07:25 AM

Quote:

Originally Posted by elcore

Hopefully, the BSD kernel will have the legacy VGA console, and will support X at that point.

As if the BSD kernels ever had console scrollback on them...

It's a Linux only feature mistake, people!

elcore · 09-17-2022, 07:27 AM

Quote:

Originally Posted by hazel

Would it actually be possible to build and use a BSD kernel within Linux? I know there is a version of Debian that uses the HURD kernel, so perhaps it's not outrageous.

Depends on what you consider "Linux", FWIW I've always thought Linux is the kernel and not userspace.
And there's plenty of BSD userspace around Slackware, so yeah I guess it's possible to replace the kernel.
Though, it must be a distribution decision to "move to CONFIG_VT=n" I don't see how's that a kernel distributor responsibility.

LuckyCyborg · 09-17-2022, 07:32 AM

Quote:

Originally Posted by hazel

Would it actually be possible to build and use a BSD kernel within Linux?

Yeah, seems to work more or less - and with the expected terrible hardware support. So, there's Debian/kfreeBSD but it's barely maintained.

However, what you think is simpler?

It's simpler to creating a Slackware/kfreeBSD or to adding mouse support to that damn KMSCON and modifying the Slackware scripts to log everything, like systemd do?

You know, in a nutshell is about something like this:

Code:

function log()
{
  LINE=$1

  echo $LINE >> /var/log/boot.log
  echo $LINE
}

It's nobody fault that the Slackware init scripts echoes in console like hell.

That's the truth! The Slackware init scripts has NO concept of logging their activity and this is The Real Problem.