Mailing List Archive

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.

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

Many thanks for this.

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

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

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.

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

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

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

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.

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

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

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

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.

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

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.

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

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.

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.

On Sat, Jan 28, 2023 at 14:41:53 +0000, Peter Humphrey wrote:
> 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.

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.

> --
> Regards,
> Peter.

--
Alan Mackenzie (Nuremberg, Germany).

hanks

On Sat, Jan 28, 2023 at 9:42?AM Peter Humphrey <peter@prh.myzen.co.uk>
wrote:

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

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.

--
Alan Mackenzie (Nuremberg, Germany).

On Wednesday, 4 October 2023 14:16:44 BST Alan Mackenzie wrote:
> 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.

Many thanks again Alan. What a stalwart you are!

--
Regards,
Peter.

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

>
>

Hello, Jorge.

On Wed, Oct 04, 2023 at 18:08:20 +0100, Jorge Almeida wrote:
> 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/

--
Alan Mackenzie (Nuremberg, Germany).

On Wed, Oct 4, 2023 at 7:59?PM Alan Mackenzie <acm@muc.de> wrote:

>
> On Wed, Oct 04, 2023 at 18:08:20 +0100, Jorge Almeida wrote:
> > 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 :)