Hello, Gentoo.

Here are the latest versions of my soft scrolling patch for the kernel
lines 5.10.xx and 5.14.xx. They fix bugs where a PC would crash if it
was initialised with a 25x80 console and later changed to a full
resolution frame buffer screen. It also now works (so I am told) for
kernels initialised with parameters like vga=791.

To use one of these (the right one for your kernel version) do:

(i) cd /usr/src/linux-5.10.61-gentoo, or similar. Extract the right
patch file to that directory. (Don't worry about having > 61 for a
kernel version. Just use it!)
(ii) patch -p1 < 5.10.61-scroll.20211007.diff.
(iii) Configure the kernel in your usual way. The extra items added by
the patch are CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK and
CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_SIZE, to be found in make
menuconfig under Device Drivers/Graphic Support/Console display driver
support. The help items for these should explain them adequately.
(iv) Build the kernel.
(v) Put the new kernel into your usual boot manager.
(vi) Reboot and enjoy!

As far as I know this patch should be safe (apart from the mysterious
alleged security problem which caused the soft scrolling to be removed
from the kernel in the first place). There is certainly nothing
malicous in it. But if it does break anything for you, you get to keep
the pieces. But if anything does go wrong, please tell me about it
(preferably here on the list, but by private email if you'd prefer), so
that I can try and fix it.

--
Alan Mackenzie (Nuremberg, Germany).


diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 06757b1d4aec..c2061813c825 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -134,6 +134,11 @@ const struct consw *conswitchp;
#define DEFAULT_BELL_DURATION (HZ/8)
#define DEFAULT_CURSOR_BLINK_MS 200

+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+static unsigned int console_soft_scrollback_size =
+ 1024 * CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_SIZE;
+#endif
+
struct vc vc_cons [MAX_NR_CONSOLES];

#ifndef VT_SINGLE_DRIVER
@@ -287,7 +292,7 @@ static inline unsigned short *screenpos(const struct vc_data *vc, int offset,
bool viewed)
{
unsigned short *p;
-
+
if (!viewed)
p = (unsigned short *)(vc->vc_origin + offset);
else if (!vc->vc_sw->con_screen_pos)
@@ -616,6 +621,218 @@ static void vc_uniscr_debug_check(struct vc_data *vc)
}
}

+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+static void con_update_softback(struct vc_data *vc)
+{
+ int l = vc->vc_softback_size / vc->vc_size_row;
+ if (l > 5)
+ {
+ vc->vc_softback_end = vc->vc_softback_buf + l * vc->vc_size_row;

On Thursday, 7 October 2021 20:46:51 BST Alan Mackenzie wrote:

Here are the latest versions of my soft scrolling patch for the kernel
lines 5.10.xx and 5.14.xx. They fix bugs where a PC would crash if it
was initialised with a 25x80 console and later changed to a full
resolution frame buffer screen. It also now works (so I am told) for
kernels initialised with parameters like vga=791.

8

Thank you for your efforts on all our behalf Alan.

--
Regards,
Peter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello, Gentoo.

Here is the latest version of my soft scrolling patch for the gentoo
kernel version 5.15.80. It will surely work on any reasonably recent
kernel version, and also on future versions. The new version doesn't
add any new functionality, it just patches the kernel giving rise to
fewer messages from the patch utility.

The purpose of the patch is to enable you to scroll a linux console text display up and down by half a screen by typing <shift><down> and
<shift><up>.

To use this patch, proceed thusly:

(i) cd /usr/src/linux-5.15.80, or similar. Get the attached patch file,
5.15.80-scroll-20221212.diff into this directory.
(ii) patch -p1 < 5.15.80-scroll-20221212.diff.
(iii) Configure the kernel in your usual way. The extra items added by
the patch are CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK and
CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_SIZE, to be found in make
menuconfig under Device Drivers/Graphic Support/Console display driver
support. The help items for these should explain them adequately.
(iv) Build the kernel.
(v) Put the new kernel into your usual boot manager.
(vi) Reboot and enjoy!

As far as I know this patch should be safe (apart from the mysterious
alleged security problem which caused the soft scrolling to be removed
from the kernel in the first place). There is certainly nothing
malicious in it. But if it does break anything for you, you get to keep
the pieces. But if anything does go wrong, please tell me about it
(preferably here on the list, but by private email if you'd prefer), so
that I can try and fix it.

--
Alan Mackenzie (Nuremberg, Germany).


* Unmerged path .config
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index b8f5bc19416d..d7aadca5107d 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -134,6 +134,11 @@ const struct consw *conswitchp;
#define DEFAULT_BELL_DURATION (HZ/8)
#define DEFAULT_CURSOR_BLINK_MS 200

+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+static unsigned int console_soft_scrollback_size =
+ 1024 * CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_SIZE;
+#endif
+
struct vc vc_cons [MAX_NR_CONSOLES];

#ifndef VT_SINGLE_DRIVER
@@ -287,7 +292,7 @@ static inline unsigned short *screenpos(const struct vc_data *vc, int offset,
bool viewed)
{
unsigned short *p;
-
+
if (!viewed)
p = (unsigned short *)(vc->vc_origin + offset);
else if (!vc->vc_sw->con_screen_pos)
@@ -616,6 +621,218 @@ static void vc_uniscr_debug_check(struct vc_data *vc)
}
}

+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+static void con_update_softback(struct vc_data *vc)
+{
+ int l = vc->vc_softback_size / vc->vc_size_row;
+ if (l > 5)
+ {
+ vc->vc_softback_end = vc->vc_softback_buf + l * vc->vc_size_row;

Many thanks for this.

I can confirm that it patches, compiles and works on 6.1 :)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello, Mike.

On Mon, Dec 12, 2022 at 19:29:43 +0000, Mike Civil wrote:

Many thanks for this.

I can confirm that it patches, compiles and works on 6.1 :)

Thanks for the testing! 6.1 _is_ up to date. :-)

--
Alan Mackenzie (Nuremberg, Germany).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, 12 December 2022 18:23:28 GMT Alan Mackenzie wrote:

Here is the latest version of my soft scrolling patch for the gentoo
kernel version 5.15.80. It will surely work on any reasonably recent
kernel version, and also on future versions. The new version doesn't
add any new functionality, it just patches the kernel giving rise to
fewer messages from the patch utility.

You've done it again! What a fine effort. It's saved me much wailing and gnashing of teeth.

Is there any chance of enabling gpm to work with it? That would save yet more generations of tooth enamel. :)

Seriously, though, it's just wonderful as it is, and we all owe you a debt.

--
Regards,
Peter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello, Peter.

On Tue, Dec 13, 2022 at 03:44:49 +0000, Peter Humphrey wrote:

On Monday, 12 December 2022 18:23:28 GMT Alan Mackenzie wrote:

Here is the latest version of my soft scrolling patch for the gentoo
kernel version 5.15.80. It will surely work on any reasonably recent kernel version, and also on future versions. The new version doesn't
add any new functionality, it just patches the kernel giving rise to
fewer messages from the patch utility.

You've done it again! What a fine effort. It's saved me much wailing and gnashing of teeth.

Thanks for that!

Is there any chance of enabling gpm to work with it? That would save
yet more generations of tooth enamel. :)

Yes, that's been annoying me for some time, too - when the screen is
scrolled, and one tries to mark a portion of text with GPM, it gets the
text that was on the screen before the scroll, and corrupts the display
of the text.

I had a look at it last night, and the problem is that the kernel
doesn't currently store the 32-bit unicode characters which have been
scrolled off the screen - just the 8-bit character glyph codes together
with the 8-bit colour information. So it would triple the amount of information stored for each character position. That surely shouldn't
be a problem on today's machines, though - even with FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_SIZE set to 512 kB, that would only
be 1.5 MB per console.

So yes, this should be doable. It's definitely more than a day's work,
almost certainly less than a month's. I'll see what I can manage.

Seriously, though, it's just wonderful as it is, and we all owe you a debt.

Thanks again!

--
Regards,
Peter.

--
Alan Mackenzie (Nuremberg, Germany).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello again, Peter.

On Wed, Dec 14, 2022 at 10:53:07 +0000, Alan Mackenzie wrote:

On Tue, Dec 13, 2022 at 03:44:49 +0000, Peter Humphrey wrote:

On Monday, 12 December 2022 18:23:28 GMT Alan Mackenzie wrote:

Here is the latest version of my soft scrolling patch for the gentoo kernel version 5.15.80. It will surely work on any reasonably recent kernel version, and also on future versions. The new version doesn't
add any new functionality, it just patches the kernel giving rise to fewer messages from the patch utility.

You've done it again! What a fine effort. It's saved me much wailing and gnashing of teeth.

Thanks for that!

Is there any chance of enabling gpm to work with it? That would save
yet more generations of tooth enamel. :)

Yes, that's been annoying me for some time, too - when the screen is scrolled, and one tries to mark a portion of text with GPM, it gets the
text that was on the screen before the scroll, and corrupts the display
of the text.

I had a look at it last night, and the problem is that the kernel
doesn't currently store the 32-bit unicode characters which have been scrolled off the screen - just the 8-bit character glyph codes together
with the 8-bit colour information. So it would triple the amount of information stored for each character position. That surely shouldn't
be a problem on today's machines, though - even with FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_SIZE set to 512 kB, that would only
be 1.5 MB per console.

So yes, this should be doable. It's definitely more than a day's work, almost certainly less than a month's. I'll see what I can manage.

Seriously, though, it's just wonderful as it is, and we all owe you a
debt.

Thanks again!

I've got a first version of a patch which attempts to handle GPM in
conjunction with scrolling. It's imperfect - for example, I can't get it
to select anything the first 66 lines of the console's displayed boot-up messages. Nevertheless it may be useful.

In particular, moving the mouse over an already scrolled area no longer corrupts that area. Also, one can select text from a scrolled area.

To use it, please apply the supplied patch ON TOP OF the patch I posted
here on 12th December. Proceed as documented in that post, up until configuring the kernel - in Device drivers/Graphic support/Console
display driver support, there's an extra item "Enable a working GPM for scrolled back scrollback buffer in System RAM" which should be enabled by default. Check this is set up properly. Then build and install the
kernel. Then reboot into it and try it out.

Note that it uses ~twice as much memory as the previous scrolling
buffers, giving a total of ~three times as much memory used. This
shouldn't really be a problem on a modern machine with 16GB or 32GB of
RAM.

Please let me know of any problems you encounter with this new facility,
so that I can try to fix them. Thanks!

--
Regards,
Peter.

--
Alan Mackenzie (Nuremberg, Germany).


diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index d7aadca5107d..c453c6031098 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -291,6 +291,28 @@ static inline bool con_should_update(const struct vc_data *vc)
static inline unsigned short *screenpos(const struct vc_data *vc, int offset,
bool viewed)
{
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+ unsigned long softback_pos, scrolled_expanse;
+
+ if (vc->vc_softback_curr == vc->vc_origin)
+ return (unsigned short *)(vc->vc_origin + offset);
+ else {
+ scrolled_expanse = vc->vc_softback_in - vc->vc_softback_curr;
+ if (scrolled_expanse < 0)
+ scrolled_expanse += vc->vc_softback_end
+ - vc->vc_softback_buf;
+ if (offset >= scrolled_expanse)
+ return (unsigned short *)(vc->vc_origin
+ + (offset - scrolled_expanse));
+ else {
+ softback_pos = vc->vc_softback_curr + offset;
+ if (softback_pos >= vc->vc_softback_end)
+ softback_pos -= vc->vc_softback_end
+ - vc->vc_softback_buf;
+ }
+ }
+ return (unsigned short *)softback_pos;
+#else
unsigned short *p;

if (!view

Hello, Peter,

thanks for the reply. The photo was extremely helpful!

On Sat, Dec 31, 2022 at 09:42:54 +0000, Peter Humphrey wrote:

Morning Alan,

On Thursday, 29 December 2022 19:50:18 GMT Alan Mackenzie wrote:

I've got a first version of a patch which attempts to handle GPM in conjunction with scrolling. It's imperfect - for example, I can't get it to select anything the first 66 lines of the console's displayed boot-up messages. Nevertheless it may be useful.

[ .... ]

Please let me know of any problems you encounter with this new facility,
so that I can try to fix them. Thanks!

Bad news, I'm afraid. After following your instructions carefully, the
new kernel hangs early in the boot process. The first time I tried it
it seemed to be just as the first HID message had been displayed; the
second time I didn't see that (could be my eyes).

I've attached a photo of the console.

The interesting bit of the photo is right at the end, where the INIT:
version 3.05 booting appears. The corresponding section from my
(successful) boot is:

[ 4.007014] Write protecting the kernel read-only data: 24576k
[ 4.008379] Freeing unused kernel image (text/rodata gap) memory: 2036K
[ 4.009611] Freeing unused kernel image (rodata/data gap) memory: 1364K
[ 4.010670] Run /sbin/init as init process
INIT: version 3.05 booting
[ 4.041455] setfont (884) used greatest stack depth: 13584 bytes left
[ 4.048471] init-early.sh (882) used greatest stack depth: 12888 bytes left

OpenRC 0.42.1 is starting up Gentoo Linux (x86_64)

* Mounting /proc ...
* Mounting /run ...
* /run/openrc: creating directory
* /run/lock: creating directory
* /run/lock: correcting owner

What I see is a message saying something about init-early.sh being
called. I don't know what, exactly, is calling it, but I tracked the
file down to /lib/rc/sh/init-early.sh. It is a part of rc-init, despite
the message being printed with a kernel style time stamp. This message
doesn't appear in your photo. I'm guessing init-early.sh was called,
but never returned.

init-early.sh does two things: it sets a console font (see the message
about setfont) and sets a key mapping. It does that via symbolic links
to /etc/init.d. The console font is more interesting, here. It
installs the font which is in /lib/rc/console/font.

What I'm thinking here is that you might be installing a font which is
bigger than the 8x16 standard that you appear to be booting with. To
check this, would you please do:

# file /lib/rc/console/font

, which should return a message like:

/lib/rc/console/font: Linux/i386 PC Screen Font v1 data, 256 characters, Unicode directory, 8x16

What is the size of this font, here (where it says 8x16 for my font)?
The reason I ask is, I've got a horrible suspicion that one of the C
functions which copies screen data when the screen size is changed can
only copy to a same sized or (possibly) _bigger_ screen (i.e. with a
smaller font). If this is indeed the case, it might explain why you're
seeing a hang, here.

--
Regards,
Peter.

--
Alan Mackenzie (Nuremberg, Germany).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Alan,
On Saturday, 31 December 2022 14:08:43 GMT you wrote:

What I'm thinking here is that you might be installing a font which is
bigger than the 8x16 standard that you appear to be booting with. To
check this, would you please do:

# file /lib/rc/console/font

, which should return a message like:

/lib/rc/console/font: Linux/i386 PC Screen Font v1 data, 256 characters, Unicode directory, 8x16

What is the size of this font, here (where it says 8x16 for my font)?
The reason I ask is, I've got a horrible suspicion that one of the C functions which copies screen data when the screen size is changed can
only copy to a same sized or (possibly) _bigger_ screen (i.e. with a
smaller font). If this is indeed the case, it might explain why you're seeing a hang, here.

I think you've put your finger on it:

$ file /lib/rc/console/font
/lib/rc/console/font: Linux/i386 PC Screen Font v2 data, 256 characters, Unicode directory, 22x11

I use consolefont="ter-122n" from the terminus-font package. It's a long time since I was able to read a high-resolution screen in its native resolution.

Is there some way I can get the UEFI BIOS to boot with that font, or a larger one? Or perhaps let the system boot without setting a font and then changing
it later?

Neither of those looks easy to do. I'd better have a good root through the
BIOS options to start with.

--
Regards,
Peter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello again, Peter.

On Sat, Dec 31, 2022 at 15:47:01 +0000, Peter Humphrey wrote:

Hello Alan,
On Saturday, 31 December 2022 14:08:43 GMT you wrote:

What I'm thinking here is that you might be installing a font which is bigger than the 8x16 standard that you appear to be booting with. To
check this, would you please do:

# file /lib/rc/console/font

, which should return a message like:

/lib/rc/console/font: Linux/i386 PC Screen Font v1 data, 256 characters,
Unicode directory, 8x16

What is the size of this font, here (where it says 8x16 for my font)?
The reason I ask is, I've got a horrible suspicion that one of the C functions which copies screen data when the screen size is changed can
only copy to a same sized or (possibly) _bigger_ screen (i.e. with a smaller font). If this is indeed the case, it might explain why you're seeing a hang, here.

I think you've put your finger on it:

$ file /lib/rc/console/font
/lib/rc/console/font: Linux/i386 PC Screen Font v2 data, 256 characters, Unicode directory, 22x11

I use consolefont="ter-122n" from the terminus-font package. It's a long time since I was able to read a high-resolution screen in its native resolution.

Is there some way I can get the UEFI BIOS to boot with that font, or a larger one? Or perhaps let the system boot without setting a font and then changing it later?

Probably, but it would be better if I just fixed the bug(s) in my changes to the kernel. Changing font size is something one should be able to do.

Neither of those looks easy to do. I'd better have a good root through the BIOS options to start with.

A happy new year to you (and everybody else here), and give me somewhere between a few hours and a few days, and this bug should get fixed.

Again, thanks for such effective testing!

--
Regards,
Peter.

--
Alan Mackenzie (Nuremberg, Germany).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thanks
Dave

On Sat, Dec 31, 2022, 11:13 AM Alan Mackenzie <acm@muc.de> wrote:

Hello again, Peter.

On Sat, Dec 31, 2022 at 15:47:01 +0000, Peter Humphrey wrote:

Hello Alan,
On Saturday, 31 December 2022 14:08:43 GMT you wrote:

What I'm thinking here is that you might be installing a font which is bigger than the 8x16 standard that you appear to be booting with. To check this, would you please do:

# file /lib/rc/console/font

, which should return a message like:

/lib/rc/console/font: Linux/i386 PC Screen Font v1 data, 256

characters,

Unicode directory, 8x16

What is the size of this font, here (where it says 8x16 for my font)?
The reason I ask is, I've got a horrible suspicion that one of the C functions which copies screen data when the screen size is changed can only copy to a same sized or (possibly) _bigger_ screen (i.e. with a smaller font). If this is indeed the case, it might explain why you're seeing a hang, here.

I think you've put your finger on it:

$ file /lib/rc/console/font
/lib/rc/console/font: Linux/i386 PC Screen Font v2 data, 256 characters, Unicode directory, 22x11

I use consolefont="ter-122n" from the terminus-font package. It's a long

time

since I was able to read a high-resolution screen in its native

resolution.

Is there some way I can get the UEFI BIOS to boot with that font, or a

larger

one? Or perhaps let the system boot without setting a font and then

changing

it later?

Probably, but it would be better if I just fixed the bug(s) in my changes
to
the kernel. Changing font size is something one should be able to do.

Neither of those looks easy to do. I'd better have a good root through

the

BIOS options to start with.

A happy new year to you (and everybody else here), and give me somewhere between a few hours and a few days, and this bug should get fixed.

Again, thanks for such effective testing!

--
Regards,
Peter.

--
Alan Mackenzie (Nuremberg, Germany).

<div dir="auto"><br>Thanks<br><div data-smartmail="gmail_signature">Dave</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Dec 31, 2022, 11:13 AM Alan Mackenzie &lt;<a href="mailto:acm@muc.de">acm@muc.de</a>&gt; wrote:<br><
/div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello again, Peter.<br>

On Sat, Dec 31, 2022 at 15:47:01 +0000, Peter Humphrey wrote:<br>
&gt; Hello Alan,<br>
&gt; On Saturday, 31 December 2022 14:08:43 GMT you wrote:<br>

&gt; &gt; What I&#39;m thinking here is that you might be installing a font which is<br>
&gt; &gt; bigger than the 8x16 standard that you appear to be booting with.  To<br>
&gt; &gt; check this, would you please do:<br>

&gt; &gt;     # file /lib/rc/console/font<br>

&gt; &gt; , which should return a message like:<br>

&gt; &gt;     /lib/rc/console/font: Linux/i386 PC Screen Font v1 data, 256 characters,<br>
&gt; &gt; Unicode directory, 8x16<br>

&gt; &gt; What is the size of this font, here (where it says 8x16 for my font)?<br>
&gt; &gt; The reason I ask is, I&#39;ve got a horrible suspicion that one of the C<br>
&gt; &gt; functions which copies screen data when the screen size is changed can<br>
&gt; &gt; only copy to a same sized or (possibly) _bigger_ screen (i.e. with a<br>
&gt; &gt; smaller font).  If this is indeed the case, it might explain why you&#39;re<br>
&gt; &gt; seeing a hang, here.<br>

&gt; I think you&#39;ve put your finger on it:<br>

&gt; $ file /lib/rc/console/font<br>
&gt; /lib/rc/console/font: Linux/i386 PC Screen Font v2 data, 256 characters, <br>
&gt; Unicode directory, 22x11<br>

&gt; I use consolefont=&quot;ter-122n&quot; from the terminus-font package. It&#39;s a long time <br>
&gt; since I was able to read a high-resolution screen in its native resolution.<br>

&gt; Is there some way I can get the UEFI BIOS to boot with that font, or a larger <br>
&gt; one? Or perhaps let the system boot without setting a font and then changing <br>
&gt; it later?<br>

Probably, but it would be better if I just fixed the bug(s) in my changes to<br>
the kernel.  Changing font size is something one should be able to do.<br>

&gt; Neither of those looks easy to do. I&#39;d better have a good root through the <br>
&gt; BIOS options to start with.<br>

A happy new year to you (and everybody else here), and give me somewhere<br> between a few hours and a few days, and this bug should get fixed.<br>

Again, thanks for such effective testing!<br>

&gt; -- <br>
&gt; Regards,<br>
&gt; Peter.<br>

-- <br>
Alan Mackenzie (Nuremberg, Germany).<br>

</blockquote></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, 1 January 2023 15:13:02 GMT Alan Mackenzie wrote:

$ file /lib/rc/console/font
/lib/rc/console/font: Linux/i386 PC Screen Font v2 data, 256 characters, Unicode directory, 22x11

I use consolefont="ter-122n" from the terminus-font package. It's a long time since I was able to read a high-resolution screen in its native resolution.

That's a nice font. I could get used to it if I wasn't so attached to
the 8x16 font.

[OT]
Yes, I like it. I'd like it even better if I could redefine the zero character without the central dot (which I believe is an American affectation) because the central dot makes the 0 resemble an 8 too closely. Instead I'd change the outline shape. Then Os and 0s would more resemble their usual printed and GUI forms. I know this wouldn't be possible on smaller sizes, but it should be possible at 11x22.

In fact I did try doing that once with a font editor, but it couldn't handle the whole font set properly. Perhaps I should look into it again.
[/OT]

8

The included patch is still imperfect. When booting in 11x22, it doesn't handle the early boot messages at all well. Also, I'm a little confused
by what a low-level scroll function is meant to do - sometimes, scrolling happens when you type a CR, and want a line on the screen to be space
filled. Other times, you type <shift><PgUp> and don't want any space
filling to happen. So I'm not convinced that scrolling, invoked by, say,
an editor program, will work correctly.

Just a quick test shows it to work here. If I find anything I'll raise a flag.

Many thanks again, Alan.

--
Regards,
Peter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello, Peter.

On Sat, Dec 31, 2022 at 16:13:23 +0000, Alan Mackenzie wrote:

On Sat, Dec 31, 2022 at 15:47:01 +0000, Peter Humphrey wrote:

Hello Alan,
On Saturday, 31 December 2022 14:08:43 GMT you wrote:

[ .... ]

I think you've put your finger on it:

$ file /lib/rc/console/font
/lib/rc/console/font: Linux/i386 PC Screen Font v2 data, 256 characters, Unicode directory, 22x11

I use consolefont="ter-122n" from the terminus-font package. It's a long time
since I was able to read a high-resolution screen in its native resolution.

That's a nice font. I could get used to it if I wasn't so attached to
the 8x16 font.

Is there some way I can get the UEFI BIOS to boot with that font, or a larger
one? Or perhaps let the system boot without setting a font and then changing
it later?

Probably, but it would be better if I just fixed the bug(s) in my changes to the kernel. Changing font size is something one should be able to do.

OK, the bug was that I was trying to free memory by calling the wrong
kernel function kfree, when it should have been kvfree. With that
correction, the kernel now boots in 11x22, at least for me.

Neither of those looks easy to do. I'd better have a good root through the BIOS options to start with.

A happy new year to you (and everybody else here), and give me somewhere between a few hours and a few days, and this bug should get fixed.

The included patch is still imperfect. When booting in 11x22, it doesn't handle the early boot messages at all well. Also, I'm a little confused
by what a low-level scroll function is meant to do - sometimes, scrolling happens when you type a CR, and want a line on the screen to be space
filled. Other times, you type <shift><PgUp> and don't want any space
filling to happen. So I'm not convinced that scrolling, invoked by, say,
an editor program, will work correctly.

Again, thanks for such effective testing!

So, please try the attached patch, which is "at the same level" as my
patch from three days ago. For anybody who wants to try it new, I'm
repeating the instructions from that post:

To use it, please apply the supplied patch ON TOP OF the patch I
posted here on 12th December. Proceed as documented in that post,
up until configuring the kernel - in Device drivers/Graphic
support/Console display driver support, there's an extra item
"Enable a working GPM for scrolled back scrollback buffer in System
RAM" which should be enabled by default. Check this is set up
properly. Then build and install the kernel. Then reboot into it
and try it out.

--
Regards,
Peter.

--
Alan Mackenzie (Nuremberg, Germany).


diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index d7aadca5107d..7bea89f03e75 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -291,6 +291,28 @@ static inline bool con_should_update(const struct vc_data *vc)
static inline unsigned short *screenpos(const struct vc_data *vc, int offset,
bool viewed)
{
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+ unsigned long softback_pos, scrolled_expanse;
+
+ if (vc->vc_softback_curr == vc->vc_origin)
+ return (unsigned short *)(vc->vc_origin + offset);
+ else {
+ scrolled_expanse = vc->vc_softback_in - vc->vc_softback_curr;
+ if (scrolled_expanse < 0)
+ scrolled_expanse += vc->vc_softback_end
+ - vc->vc_softback_buf;
+ if (offset >= scrolled_expanse)
+ return (unsigned short *)(vc->vc_origin
+ + (offset - scrolled_expanse));
+ else {
+ softback_pos = vc->vc_softback_curr + offset;
+ if (softback_pos >= vc->vc_softback_end)
+ softback_pos -= vc->vc_softback_end
+ - vc->vc_softback_buf;
+ }
+ }
+ return (unsigned short *)softback_pos;
+#else
unsigned short *p;

if (!view

Hello, Peter.

On Sun, Jan 01, 2023 at 15:13:02 +0000, Alan Mackenzie wrote:

On Sat, Dec 31, 2022 at 16:13:23 +0000, Alan Mackenzie wrote:

On Sat, Dec 31, 2022 at 15:47:01 +0000, Peter Humphrey wrote:

Hello Alan,
On Saturday, 31 December 2022 14:08:43 GMT you wrote:

[ .... ]

I think you've put your finger on it:

$ file /lib/rc/console/font
/lib/rc/console/font: Linux/i386 PC Screen Font v2 data, 256 characters, Unicode directory, 22x11

I use consolefont="ter-122n" from the terminus-font package. It's a long time
since I was able to read a high-resolution screen in its native resolution.

That's a nice font. I could get used to it if I wasn't so attached to
the 8x16 font.

[ .... ]

The included patch is still imperfect. When booting in 11x22, it doesn't handle the early boot messages at all well. Also, I'm a little confused
by what a low-level scroll function is meant to do - sometimes, scrolling happens when you type a CR, and want a line on the screen to be space
filled. Other times, you type <shift><PgUp> and don't want any space
filling to happen. So I'm not convinced that scrolling, invoked by, say,
an editor program, will work correctly.

OK, I'm now including a revised patch which is less imperfect. ;-)

To use it, please apply it to the vanilla gentoo-sources 5.15.88 (or
similar) with the usual:

patch -p1 < 5.15.80-GPM.20230126.diff

, followed by configuring in CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
and CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_GPM, and setting an
appropriate scrollback buffer size as already done. The ..._GPM is new,
but is enabled by default. Build and install the kernel, then reboot
into it, to try it out.

I think it will work better than the previous patch.

To use it, please apply the supplied patch ON TOP OF the patch I
posted here on 12th December. Proceed as documented in that post,
up until configuring the kernel - in Device drivers/Graphic
support/Console display driver support, there's an extra item
"Enable a working GPM for scrolled back scrollback buffer in System
RAM" which should be enabled by default. Check this is set up
properly. Then build and install the kernel. Then reboot into it
and try it out.

Again, on any problems please let me know and I'll try to fix them. As
ever, there are no guarantees, etc., etc., etc. My only promise is that there's no malicious code in the patch.

--
Regards,
Peter.

--
Alan Mackenzie (Nuremberg, Germany).


diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index b8f5bc19416d..58332d1dd923 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -134,6 +134,11 @@ const struct consw *conswitchp;
#define DEFAULT_BELL_DURATION (HZ/8)
#define DEFAULT_CURSOR_BLINK_MS 200

+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+static unsigned int console_soft_scrollback_size =
+ 1024 * CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_SIZE;
+#endif
+
struct vc vc_cons [MAX_NR_CONSOLES];

#ifndef VT_SINGLE_DRIVER
@@ -286,8 +291,38 @@ static inline bool con_should_update(const struct vc_data *vc)
static inline unsigned short *screenpos(const struct vc_data *vc, int offset,
bool viewed)
{
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+ unsigned long softback_pos, scrolled_expanse;
+
+ if (vc->vc_softback_curr == vc->vc_origin) /* Should never happen! */
+ return (unsigned short *)(vc->vc_origin + offset);
+ else {
+ /* OLD STOUGH, 2023-01-26 */
+ /* scrolled_expanse = vc->vc_softback_in - vc->vc_softback_curr; */
+ /* if (scrolled_expanse < 0) */
+ /* scrolled_expanse

This is a multi-part message in MIME format.

On Thursday, 26 January 2023 20:28:36 GMT Alan Mackenzie wrote:

8

Again, on any problems please let me know and I'll try to fix them. As
ever, there are no guarantees, etc., etc., etc. My only promise is that there's no malicious code in the patch.

Good news! Well, partly... :)

I applied the new patch to 5.15.88 and it seems fine. I'll have to test it in use and let you know.

Patching 6.1.8 failed, though, whereas the previous 5.15.80-scroll. 20221212.diff succeeded:

# patch -p1 < /usr/local/src/5.15.80-GPM.20230126.diff
patching file drivers/tty/vt/vt.c
Hunk #37 succeeded at 4748 (offset -1 lines).
Hunk #38 succeeded at 5049 (offset -1 lines).
Hunk #39 FAILED at 5353.
1 out of 39 hunks FAILED -- saving rejects to file drivers/tty/vt/vt.c.rej patching file drivers/video/console/Kconfig
Hunk #1 succeeded at 99 (offset 1 line).
patching file drivers/video/fbdev/core/fbcon.c
Hunk #1 succeeded at 3171 (offset 19 lines).
patching file include/linux/console_struct.h
Hunk #2 FAILED at 170.
1 out of 2 hunks FAILED -- saving rejects to file include/linux/ console_struct.h.rej
patching file include/linux/vt_kern.h
Hunk #1 succeeded at 114 (offset -1 lines).

I've attached the reject files.

--
Regards,
Peter.

--- drivers/tty/vt/vt.c
+++ drivers/tty/vt/vt.c
@@ -5353,10 +5965,19 @@ EXPORT_SYMBOL_GPL(screen_glyph);

u32 screen_glyph_unicode(const struct vc_data *vc, int n)
{
- struct uni_screen *uniscr = get_vc_uniscr(vc);
+ int y = n / vc->vc_cols, x = n % vc->vc_cols;
+ uint32_t *ln = vc->vc_uniscr_curr + y * vc->vc_cols;

- if (uniscr)
- return uniscr->lines[n / vc->vc_cols][n % vc->vc_cols];
+ if (vc->vc_uniscr_curr) {
+ if (ln >= vc_uniscr_buf_end(vc))
+ ln -= vc->vc_uniscr_char_size;
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_GPM
+ ln -= vc->vc_softback_lines * vc->vc_cols;
+ if (ln < vc->vc_uniscr_buf)
+ ln += vc->vc_uniscr_char_size;
+#endif
+ return ln[x];
+ }
return inverse_translate(vc, screen_glyph(vc, n * 2), 1);
}
EXPORT_SYMBOL_GPL(screen_glyph_unicode);

--- include/linux/console_struct.h
+++ include/linux/console_struct.h
@@ -170,7 +181,11 @@ struct vc_data {
struct vc_data **vc_display_fg; /* [!] Ptr to var holding fg console for this display */

Hello, Peter.

On Fri, Jan 27, 2023 at 12:24:41 +0000, Peter Humphrey wrote:

On Thursday, 26 January 2023 20:28:36 GMT Alan Mackenzie wrote:

8

Again, on any problems please let me know and I'll try to fix them. As ever, there are no guarantees, etc., etc., etc. My only promise is that there's no malicious code in the patch.

Good news! Well, partly... :)

I applied the new patch to 5.15.88 and it seems fine. I'll have to test it in use and let you know.

I have since found a few bugs in that patch. Mainly they're to do with
losing 18 lines[*] GPM-ability at the earliest boot messages, when
changing font size, and things like that.

[*] 18 lines is the difference between 49 lines (from an 11x22 font such
as ter-122n) and 67 lines (from an 8x16 font like lat1-16) which fit on
the screen.

I've also discovered that when CONFIG_LOGO (i.e. displaying Tux at boot
up) is enabled, all boot messages which preceded the Tuxes become
invisible to GPM, and they cannot be selected. I don't (yet) know why
this is happening, but the obvious workaround is to disable CONFIG_LOGO
in one's kernel configuration.

I've found yet another bug which it's taken me a few hours to determine
is nothing to do with me. It goes like this: boot up in an 11x22 font
such as ter-122n, and move the mouse on that screen. Run the command
setfont lat1-16, which will resize the existing text. The GPM mouse is
now restricted to the 174x49 rectangle in the top left of the screen.
This is the bug. To free it, switch to a different tty and move the
mouse there. On returning to the first tty, the mouse can now be moved
over the entire screen.

The cause of this bug is that GPM does not connect up with screen
resizing events. The only time it determines a tty's size is when it
detects the tty has been switched. Not a big bug, but somewhat
annoying.

Patching 6.1.8 failed, though, whereas the previous 5.15.80-scroll. 20221212.diff succeeded:

I haven't actually looked at any versions except for 5.15.80 and 5.15.88
so far.

# patch -p1 < /usr/local/src/5.15.80-GPM.20230126.diff
patching file drivers/tty/vt/vt.c
Hunk #37 succeeded at 4748 (offset -1 lines).
Hunk #38 succeeded at 5049 (offset -1 lines).
Hunk #39 FAILED at 5353.
1 out of 39 hunks FAILED -- saving rejects to file drivers/tty/vt/vt.c.rej patching file drivers/video/console/Kconfig
Hunk #1 succeeded at 99 (offset 1 line).
patching file drivers/video/fbdev/core/fbcon.c
Hunk #1 succeeded at 3171 (offset 19 lines).
patching file include/linux/console_struct.h
Hunk #2 FAILED at 170.
1 out of 2 hunks FAILED -- saving rejects to file include/linux/ console_struct.h.rej
patching file include/linux/vt_kern.h
Hunk #1 succeeded at 114 (offset -1 lines).

I've attached the reject files.

Thanks for these! It looks like it'll probably be straightforward to
amend the patch for 6.1.8. Are you currently running 6.1.8 as your main kernel?

Anyhow, I'll probably post another patch with corrections in the next
day or two. Thanks for the testing!

--
Regards,
Peter.

--- drivers/tty/vt/vt.c
+++ drivers/tty/vt/vt.c
@@ -5353,10 +5965,19 @@ EXPORT_SYMBOL_GPL(screen_glyph);

u32 screen_glyph_unicode(const struct vc_data *vc, int n)
{
- struct uni_screen *uniscr = get_vc_uniscr(vc);
+ int y = n / vc->vc_cols, x = n % vc->vc_cols;
+ uint32_t *ln = vc->vc_uniscr_curr + y * vc->vc_cols;

- if (uniscr)
- return uniscr->lines[n / vc->vc_cols][n % vc->vc_cols];
+ if (vc->vc_uniscr_curr) {
+ if (ln >= vc_uniscr_buf_end(vc))
+ ln -= vc->vc_uniscr_char_size;
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_GPM
+ ln -= vc->vc_softback_lines * vc->vc_cols;
+ if (ln < vc->vc_uniscr_buf)
+ ln += vc->vc_uniscr_char_size;
+#endif
+ return ln[x];
+ }
return inverse_translate(vc, screen_glyph(vc, n * 2), 1);
}
EXPORT_SYMBOL_GPL(screen_glyph_unicode);

--- include/linux/console_struct.h
+++ include/linux/console_struct.h
@@ -170,7 +181,11 @@ struct vc_data {
struct vc_data **vc_display_fg; /* [!] Ptr to var holding fg console for this display */
struct uni_pagedir *vc_uni_pagedir;
struct uni_pagedir **vc_uni_pagedir_loc; /* [!] Location of uni_pagedir variable for this console */
- struct uni_screen *vc_uni_screen; /* unicode screen content */ +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_GPM
+ uint32_t *vc_uniscr_buf; /* Address of unicode screen content */
+ unsigned int vc_uniscr_char_size; /* Size of *vc-uniscr_buf in 32-bit chars */
+ uint32_t *vc_uniscr_curr; /* Pos of first char of (unscrolled) screen */
+#endif
/* additional information is in vt_kern.h */
};

--
Alan Mackenzie (Nuremberg, Germany).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, 27 January 2023 22:31:17 GMT Alan Mackenzie wrote:

On Fri, Jan 27, 2023 at 12:24:41 +0000, Peter Humphrey wrote:

8

I've attached the reject files.

Thanks for these! It looks like it'll probably be straightforward to
amend the patch for 6.1.8. Are you currently running 6.1.8 as your main kernel?

Yes Alan, I'm running ~amd64, so 6.1.8 is the current kernel. I have 5.15.88
as a backup.

--
Regards,
Peter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)