[gentoo-user] Soft scrolling on framebuffer consoles - New versions of the patches.

[Alan Mackenzie]

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.

[Peter Humphrey]

Post by Alan Mackenzie
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.

[Alan Mackenzie]

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.

[Mike Civil]

Many thanks for this.

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

[Alan Mackenzie]

Hello, Mike.

Post by Mike Civil
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. :-)

[Peter Humphrey]

Post by Alan Mackenzie
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.

[Alan Mackenzie]

Hello, Peter.

Post by Peter Humphrey

Post by Alan Mackenzie
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!

Post by Peter Humphrey
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.

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

Thanks again!

Post by Peter Humphrey
--
Regards,
Peter.

[Alan Mackenzie]

Hello again, Peter.

Post by Alan Mackenzie

Post by Peter Humphrey

Post by Alan Mackenzie
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!

Post by Peter Humphrey
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.

Post by Peter Humphrey
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!

Post by Alan Mackenzie

Post by Peter Humphrey
--
Regards,
Peter.

[Alan Mackenzie]

Hello, Peter,

thanks for the reply. The photo was extremely helpful!

Morning Alan,

Post by Alan Mackenzie
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.

[ .... ]

Post by Alan Mackenzie
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.

[Peter Humphrey]

Hello Alan,

Post by Alan Mackenzie
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
# file /lib/rc/console/font
/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.

[Alan Mackenzie]

Hello again, Peter.

Post by Peter Humphrey
Hello Alan,

Post by Alan Mackenzie
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
# file /lib/rc/console/font
/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.

$ 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.

Post by Peter Humphrey
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!

Post by Peter Humphrey
--
Regards,
Peter.

[David Rosenbaum]

Thanks
Dave

Post by Alan Mackenzie
Hello again, Peter.

Post by Peter Humphrey
Hello Alan,

Post by Alan Mackenzie
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
# file /lib/rc/console/font
/lib/rc/console/font: Linux/i386 PC Screen Font v1 data, 256

characters,

Post by Peter Humphrey

Post by Alan Mackenzie
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.

$ 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

Post by Peter Humphrey
since I was able to read a high-resolution screen in its native

resolution.

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

larger

Post by Peter Humphrey
one? Or perhaps let the system boot without setting a font and then

changing

Post by Peter Humphrey
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.

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

the

Post by Peter Humphrey
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!

Post by Peter Humphrey
--
Regards,
Peter.

--
Alan Mackenzie (Nuremberg, Germany).

[Alan Mackenzie]

Hello, Peter.

Post by Alan Mackenzie

Post by Peter Humphrey
Hello Alan,

[ .... ]

Post by Alan Mackenzie

Post by Peter Humphrey
$ 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.

Post by Alan Mackenzie

Post by Peter Humphrey
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.

Post by Alan Mackenzie

Post by Peter Humphrey
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.

Post by Alan Mackenzie
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

Post by Alan Mackenzie

Post by Peter Humphrey

Post by Alan Mackenzie
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.

[Peter Humphrey]

Post by Alan Mackenzie

Post by Peter Humphrey
$ 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

Post by Alan Mackenzie
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.

[Alan Mackenzie]

Hello, Peter.

Post by Alan Mackenzie

Post by Peter Humphrey
Hello Alan,

[ .... ]

Post by Peter Humphrey
$ 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.

[ .... ]

Post by Alan Mackenzie
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.

Post by Alan Mackenzie

Post by Peter Humphrey

Post by Alan Mackenzie
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.

Post by Alan Mackenzie

Post by Peter Humphrey
--
Regards,
Peter.

[Peter Humphrey]

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

--->8

Post by Alan Mackenzie
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.

[Alan Mackenzie]

Hello, Peter.

Post by Peter Humphrey
--->8

Post by Alan Mackenzie
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.

Post by Peter Humphrey
Patching 6.1.8 failed, though, whereas the previous 5.15.80-scroll.

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

Post by Peter Humphrey
# 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!

Post by Peter Humphrey
--
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 */
};

[Peter Humphrey]

--->8

Post by Alan Mackenzie

Post by Peter Humphrey
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.

[Alan Mackenzie]

Hello, Peter.

I have another version of the patch which makes GPM usable on scrolled
consoles. I'd like to think that it's now final.

Post by Peter Humphrey
--->8

Post by Alan Mackenzie

Post by Peter Humphrey
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.

OK, I'm enclosing a patch for each version, 5.15.x and 6.1.y. I'm not
aware of any outstanding bugs in these patches. In particular, the
following have been fixed since the previous version:
(i) The synchronisation between the "mouse" character buffer and the
contents of the screen is now 100%. In particular, when changing
fonts (e.g. at bootup), and when the Tux logos get removed from the
screen, things continue working.
(ii) CONFIG_LOGO (i.e. the Tuxes on bootup) can now be freely configured
without losing functionality.

Just a quick reminder of how to use these files for anybody else who
might be interested:
(i) cd /usr/src/linux-5.15.88-gentoo, or similar. (Or
...-6.1.x-gentoo).
(ii) patch -p1 < 5.15.80-GPM.20230203.diff (or the other one).
(iii) Configure the kernel as normal. Additionally, under Device
drivers/Graphic Support/Console display driver support, enable
CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK, set the buffer size to
taste (it's default is 128 kB) and accept the default enablement of
CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_GPM.
(iv) Build the kernel and install it into your boot manager.
(v) Reboot and enjoy! You can now use GPM in scrolled consoles.

Post by Peter Humphrey
--
Regards,
Peter.

[Alan Mackenzie]

Hello, Gentoo.

On Fri, Feb 03, 2023 at 18:56:27 +0000, Alan Mackenzie wrote:

The topic of this post is my kernel patch which enables soft scrolling
on Linux tty's with <shift><PgUp> and <shift><PgDn>, and also enables
the GPM mouse utility on those scrolled regions.

Currently, the patch I posted some months ago works on all 6.1.x
kernels, and very likely works on 6.2.x, too. In kernel 6.3.1, some
significant refactoring was done by the kernel people, necessitating a
new version of the patch, called 6.3.11-GPM.20231004.diff. I've tested
this on 6.3.11 and 6.5.5.

Just a quick reminder of how to use these files for anybody else who
might be interested:
(i) cd /usr/src/linux-6.3.11-gentoo, or similar. (Or ...-6.1.x-gentoo).
(ii) patch -p1 < 6.3.11-GPM.20231004.diff (or the other one).
(iii) Configure the kernel as normal. Additionally, under Device
drivers/Graphic Support/Console display driver support, enable
CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK, set the buffer size to taste
(it's default is 128 kB) and accept the default enablement of
CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_GPM.
(iv) Build the kernel and install it into your boot manager.
(v) Reboot and enjoy! You can now use GPM in scrolled consoles.

Just a warning: if you copy your kernel .config from a 6.1.x kernel, and
use make oldconfig to generate a new kernel for 6.3.x etc., you will
have to enable CONFIG_HID_SUPPORT, otherwise your USB keyboard and mouse
will be dead on bootup. ;-(

The usual disclaimers apply, here. If this patch breaks anything for
you, you get to join the pieces back together again. But if this does
happen, please let me know, so that I can try to fix the bug. My only
promise is that there's nothing malicious in the patch.

As well as 6.3.11-GPM.20231004.diff, I'm reposting
6.1.8-GPM.20230203.diff for anybody new here who wants to try it on the
current Gentoo 6.1.x kernel.

[Peter Humphrey]

Post by Alan Mackenzie
Hello, Gentoo.
The topic of this post is my kernel patch which enables soft scrolling
on Linux tty's with <shift><PgUp> and <shift><PgDn>, and also enables
the GPM mouse utility on those scrolled regions.
Currently, the patch I posted some months ago works on all 6.1.x
kernels, and very likely works on 6.2.x, too. In kernel 6.3.1, some
significant refactoring was done by the kernel people, necessitating a
new version of the patch, called 6.3.11-GPM.20231004.diff. I've tested
this on 6.3.11 and 6.5.5.
Just a quick reminder of how to use these files for anybody else who
(i) cd /usr/src/linux-6.3.11-gentoo, or similar. (Or ...-6.1.x-gentoo).
(ii) patch -p1 < 6.3.11-GPM.20231004.diff (or the other one).
(iii) Configure the kernel as normal. Additionally, under Device
drivers/Graphic Support/Console display driver support, enable
CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK, set the buffer size to taste
(it's default is 128 kB) and accept the default enablement of
CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_GPM.
(iv) Build the kernel and install it into your boot manager.
(v) Reboot and enjoy! You can now use GPM in scrolled consoles.
Just a warning: if you copy your kernel .config from a 6.1.x kernel, and
use make oldconfig to generate a new kernel for 6.3.x etc., you will
have to enable CONFIG_HID_SUPPORT, otherwise your USB keyboard and mouse
will be dead on bootup. ;-(
The usual disclaimers apply, here. If this patch breaks anything for
you, you get to join the pieces back together again. But if this does
happen, please let me know, so that I can try to fix the bug. My only
promise is that there's nothing malicious in the patch.
As well as 6.3.11-GPM.20231004.diff, I'm reposting
6.1.8-GPM.20230203.diff for anybody new here who wants to try it on the
current Gentoo 6.1.x kernel.

Many thanks again Alan. What a stalwart you are!

[Jorge Almeida]

6.3.11-GPM.20231004.diff works fine with 6.5.5 (vanilla from kernel.org)

[Alan Mackenzie]

Hello, Jorge.

6.3.11-GPM.20231004.diff works fine with 6.5.5 (vanilla from
[1]kernel.org)

Thanks for doing this testing.

References
1. http://kernel.org/

[Jorge Almeida]

Post by Alan Mackenzie

6.3.11-GPM.20231004.diff works fine with 6.5.5 (vanilla from
[1]kernel.org)

Thanks for doing this testing.

Thank _you_ for making the patch :)

[Alan Mackenzie]

Hello, Gentoo.

[ First an older post, but without quoting >s on the lines. ]

On Fri, Feb 03, 2023 at 18:56:27 +0000, Alan Mackenzie wrote:

The topic of this post is my kernel patch which enables soft scrolling
on Linux tty's with <shift><PgUp> and <shift><PgDn>, and also enables
the GPM mouse utility on those scrolled regions.

Currently, the patch I posted some months ago works on all 6.1.x
kernels, and very likely works on 6.2.x, too. In kernel 6.3.1, some
significant refactoring was done by the kernel people, necessitating a
new version of the patch, called 6.3.11-GPM.20231004.diff. I've tested
this on 6.3.11 and 6.5.5.

Just a quick reminder of how to use these files for anybody else who
might be interested:
(i) cd /usr/src/linux-6.3.11-gentoo, or similar. (Or ...-6.1.x-gentoo).
(ii) patch -p1 < 6.3.11-GPM.20231004.diff (or the other one).
(iii) Configure the kernel as normal. Additionally, under Device
drivers/Graphic Support/Console display driver support, enable
CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK, set the buffer size to taste
(it's default is 128 kB) and accept the default enablement of
CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_GPM.
(iv) Build the kernel and install it into your boot manager.
(v) Reboot and enjoy! You can now use GPM in scrolled consoles.

Just a warning: if you copy your kernel .config from a 6.1.x kernel, and
use make oldconfig to generate a new kernel for 6.3.x etc., you will
have to enable CONFIG_HID_SUPPORT, otherwise your USB keyboard and mouse
will be dead on bootup. ;-(

The usual disclaimers apply, here. If this patch breaks anything for
you, you get to join the pieces back together again. But if this does
happen, please let me know, so that I can try to fix the bug. My only
promise is that there's nothing malicious in the patch.

As well as 6.3.11-GPM.20231004.diff, I'm reposting
6.1.8-GPM.20230203.diff for anybody new here who wants to try it on the
current Gentoo 6.1.x kernel.
--
Alan Mackenzie (Nuremberg, Germany).

I've adapted this patch for kernel 6.6.13. All of the parent post still
applies, with the exception of the version numbers.

The main patch for the new kernel is 6.6.13-GPM.20240123.diff.

Additionally I've attached a smaller patch which fixes what to me was a
little glitch in the gpm utility. This was that on a triple click to
select a whole line (or sequence of lines), the (last) line got a
linefeed appended to it. The effect was that if you wanted to hoik a
line out of some screen output and execute that from the bash command
line, you couldn't edit it first. So with this patch, you no longer get
that annoying linefeed, and the highlighting is adjusted accordingly.
This patch is (as far as I'm aware, without testing) independent of the
main GPM patch.

If anybody still needs them, I've still got the patches for the 6.1
kernel, and the 6.3 and 6.5 kernels, and one or two earlier kernels too.

Have fun!

[Alan Mackenzie]

Hello, Gentoo.

On Wed, Jan 24, 2024 at 10:00:37 +0000, Alan Mackenzie wrote:

[ .... ]

Please note the corrected subject line. This version of the soft
scrolling patch is for kernel 6.6.13, or thereabouts.

[Peter Humphrey]

Post by Alan Mackenzie
Hello, Gentoo.
[ .... ]
Please note the corrected subject line. This version of the soft
scrolling patch is for kernel 6.6.13, or thereabouts.

It works well here, Alan, up to kernel version 6.7.9, but one of the 15 or so
new kernel parameters (since 6.7.8) seems to cause it to fail.

I've attached the reject file, /usr/src/linux-6.8.0-gentoo/drivers/tty/vt/
vt.c.rej.

[Alan Mackenzie]

Hello, Peter.

Post by Peter Humphrey

Post by Alan Mackenzie
Hello, Gentoo.
[ .... ]
Please note the corrected subject line. This version of the soft
scrolling patch is for kernel 6.6.13, or thereabouts.

It works well here, Alan, up to kernel version 6.7.9, but one of the 15 or so
new kernel parameters (since 6.7.8) seems to cause it to fail.
I've attached the reject file, /usr/src/linux-6.8.0-gentoo/drivers/tty/vt/
vt.c.rej.

Thanks!

I've had a look at this, now. The 6.6.13 patch appears to work on 6.7.x
(I tested it on 6.7.10 this morning).

For 6.8.1, a new patch is needed, see below. Remember, to apply it, you
need smething like:

$ patch -p1 < 6.8.1-GPS.20240402.diff

.. Have fun!

Post by Peter Humphrey
--
Regards,
Peter.

[Peter Humphrey]

Post by Alan Mackenzie
I've adapted this patch for kernel 6.6.13. All of the parent post still
applies, with the exception of the version numbers.
The main patch for the new kernel is 6.6.13-GPM.20240123.diff.
Additionally I've attached a smaller patch which fixes what to me was a
little glitch in the gpm utility. This was that on a triple click to
select a whole line (or sequence of lines), the (last) line got a
linefeed appended to it. The effect was that if you wanted to hoik a
line out of some screen output and execute that from the bash command
line, you couldn't edit it first. So with this patch, you no longer get
that annoying linefeed, and the highlighting is adjusted accordingly.
This patch is (as far as I'm aware, without testing) independent of the
main GPM patch.

Ever the star, Alan!

[David Rosenbaum]

hanks

Post by Peter Humphrey
--->8

Post by Alan Mackenzie

Post by Peter Humphrey
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.