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