Hello, Karl. On Mon, Apr 05, 2021 at 21:58:37 +0200, k...@aspodata.se wrote: > Alan Mackenzie: > > Yes, console soft scrolling is back! That essential feature that was > > stripped out of the kernel at around 5.4.x has returned!
> It is commit 087b6cb17df5834d395ab72da3f937380470ba15, > between v5.4.65 and 66. > Perhaps also 0d123a8c64fde433a, cf5a7ded53652c3d63d72, and possible > other stuff. I will confess that I don't actually have a git repository of Linux on my machine. I'd have to back it up, somehow. It would be a fair amount of work to write an efficient back-up procedure - the one I have at the moment for git repos backs up the entire repository, which would probably be excessive for Linux. Currently, I've changed a mere five files, for which I'm getting by with symbolic links in the kernel tree pointing into my home directory. > > Only this time, it's even better! Instead of one scrollback buffer > > shared between all tty's, there's now a buffer for each tty. > Great, no more missing data when switching vts. > Btw, wasn't that added in commit aabd31c421ddc730edf6d89c4ed3885e4fca5e30 > but turned off by default. There was no capability at all for one buffer per tty in framebuffer consoles. It was there for VGA consoles, and, I think, one or two others. The configuration page for it was confusing - the option for "persistent scrollback" was purely for VGAcon, though that wasn't obvious. I spent time in the past trying to get multiple buffers working, and was even considering reporting a bug. > ... > > One or two features haven't (yet) been implemented - having a > > single scroll buffer shared amongst all tty's isn't there, > ... > Is there any reason to share the buffer ? Not that I can think of. The only reason might be if somebody wanted a very large scrollback buffer, but didn't have a lot of RAM. But even so, the current default takes a total of less than 1 MB of RAM with the standard 7 tty's. Even increasing the buffer size to 10 MB, that would only come to 70 MB. Such a size of buffer would really need more sophisticated handling, with search facilities, some marking of positions, and so on. That would be a large project. > > Bug reports and other comments are welcome, of course. > git log drivers/video/console/vgacon.c etc. can give some ideas > what one is up against. Once I find some way to read it. ;-( Anyhow, the patch I have is working software, and is not going away any time soon. It means I can carry on using Linux. Just in case you're interested, the problem I had with no scrolling on tty1 was due to the way the console was initialised early on in the boot process. Its structures were initialised in a separate place from the normal init function, thus bypassing the scrollbuffer's init. When it came to re-initialising it for scrollbuffer, this partial initialisation acted as a flag not to carry on with the init. At least it caused me to learn about printk. ;-) > Regards, > /Karl Hammar -- Alan Mackenzie (Nuremberg, Germany).
