From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id B9DF51382C5 for ; Tue, 6 Apr 2021 11:05:02 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5048CE08F9; Tue, 6 Apr 2021 11:04:55 +0000 (UTC) Received: from mail.muc.de (colin.muc.de [193.149.48.1]) by pigeon.gentoo.org (Postfix) with SMTP id C2FA9E08BD for ; Tue, 6 Apr 2021 11:04:53 +0000 (UTC) Received: (qmail 69209 invoked by uid 3782); 6 Apr 2021 11:04:52 -0000 Received: from acm.muc.de (p4fe15a5c.dip0.t-ipconnect.de [79.225.90.92]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 06 Apr 2021 13:04:52 +0200 Received: (qmail 5474 invoked by uid 1000); 6 Apr 2021 11:04:52 -0000 Date: Tue, 6 Apr 2021 11:04:52 +0000 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Console scrollback is back again! Message-ID: References: <20210405195837.261E782475BF@turkos.aspodata.se> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210405195837.261E782475BF@turkos.aspodata.se> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Archives-Salt: f40ebab3-ae3c-4bd6-a406-9519fcafcbd9 X-Archives-Hash: 2c164ff98a436501bd0024203252b2be Hello, Karl. On Mon, Apr 05, 2021 at 21:58:37 +0200, karl@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).