Hello, Laurence.
On Tue, Jan 19, 2021 at 17:09:03 +0000, Laurence Perkins wrote:
> On Sun, 2021-01-17 at 05:17 +0000, Thomas Mueller wrote:
> > On Sat, 16 Jan 2021 12:01:48 +0000, Alan Mackenzie wrote:
> > > I don't know what I'll be doing, long term. For the moment, I'll
> > > be hanging onto the working kernel I've got, old though it may be
> > > (4.19.97). It might be possible (I'm not sure) to hook up a user
> > > space program to the keys <shift>-<PageUp/Down> which would take
> > > care of the scrolling. This would obviously not work with early
> > > kernel messages, but would be better than nothing. I had a look at
> > > the GNU screen source code yesterday to see how it managed such
> > > things, but it is very sparsely commented, and thus hard work to
> > > understand. Maybe I should just cut my losses, and convert to
> > > using one of the BSDs.
> > 2000 posts per day on Linux kernel list would be more than
> > unmanageable for me! I wouldn't say "almost"!
> > Is Linus Torvalds' removal of console scrolling the reason why Scroll
> > Lock does not work on the console with System Rescue CD or USB, while
> > with FreeBSD and NetBSD, I can press Scroll Lock and scroll back?
> > I like that ability but don't think Linus Torvalds is listening or
> > reading this.
> > Further, with System Rescue console, the lines/text go only partway
> > down.
> > Using screen, now at v4.8, means having to remember a lot of key
> > functions, you need a separate reference screen to look them up.
> > There is also tmux, which is part of the base system in NetBSD but
> > not FreeBSD.
> > If Linus cared about his users, he could make the kernel headers more
> > user-friendly, installing kernel headers should not be any more
> > complicated than copying or downloading.
> > Console scrolling is especially useful with an OS or distro that is
> > built from the ground up, like Gentoo, Void or Arch, as opposed to
> > being installed all at once.
> > If more Linux users would go to and try NetBSD or FreeBSD, those OSes
> > would have more users, more ideas, more ability to improve.
> > You can even cross-compile NetBSD from Linux. You'd need NetBSD
> > source tree, but don't have to do anything special to install kernel
> > headers.
> > Tom
> You're getting this second-hand since it was my brother who actually
> looked into it, so pardon anything I misremember, but the big problem
> is that adding unicode support to vgacon would need a near total
> rewrite, and nobody wants to do that since it's a terrible hackjob to
> start with.
> kmscon is slated to be the replacement. You might want to see if that
> can do what you need.
I looked kmscon up on Wikipedia, and apparently development ceased
several years ago.
What I have in mind now is writing a Linux driver, a small piece of code
which would piggy-back on the existing virtual terminal drivers, and
simply pass everything through to and from the main driver, filtering out
things relevant to scrolling, and processing these in my new driver.
I've spent the last few evenings reading up on drivers, and reading the
relevant source code from 4.19.97. I can understand the kernel
maintainers not being enthusiastic about the existing code. But that
dates from, I believe, the 1990s, when RAM was measured in megabytes, and
processor speeds in megahertz. Optimisation for speed and store usage
just isn't important any more.
> LMP
--
Alan Mackenzie (Nuremberg, Germany).
On Tue, Jan 19, 2021 at 17:09:03 +0000, Laurence Perkins wrote:
> On Sun, 2021-01-17 at 05:17 +0000, Thomas Mueller wrote:
> > On Sat, 16 Jan 2021 12:01:48 +0000, Alan Mackenzie wrote:
> > > I don't know what I'll be doing, long term. For the moment, I'll
> > > be hanging onto the working kernel I've got, old though it may be
> > > (4.19.97). It might be possible (I'm not sure) to hook up a user
> > > space program to the keys <shift>-<PageUp/Down> which would take
> > > care of the scrolling. This would obviously not work with early
> > > kernel messages, but would be better than nothing. I had a look at
> > > the GNU screen source code yesterday to see how it managed such
> > > things, but it is very sparsely commented, and thus hard work to
> > > understand. Maybe I should just cut my losses, and convert to
> > > using one of the BSDs.
> > 2000 posts per day on Linux kernel list would be more than
> > unmanageable for me! I wouldn't say "almost"!
> > Is Linus Torvalds' removal of console scrolling the reason why Scroll
> > Lock does not work on the console with System Rescue CD or USB, while
> > with FreeBSD and NetBSD, I can press Scroll Lock and scroll back?
> > I like that ability but don't think Linus Torvalds is listening or
> > reading this.
> > Further, with System Rescue console, the lines/text go only partway
> > down.
> > Using screen, now at v4.8, means having to remember a lot of key
> > functions, you need a separate reference screen to look them up.
> > There is also tmux, which is part of the base system in NetBSD but
> > not FreeBSD.
> > If Linus cared about his users, he could make the kernel headers more
> > user-friendly, installing kernel headers should not be any more
> > complicated than copying or downloading.
> > Console scrolling is especially useful with an OS or distro that is
> > built from the ground up, like Gentoo, Void or Arch, as opposed to
> > being installed all at once.
> > If more Linux users would go to and try NetBSD or FreeBSD, those OSes
> > would have more users, more ideas, more ability to improve.
> > You can even cross-compile NetBSD from Linux. You'd need NetBSD
> > source tree, but don't have to do anything special to install kernel
> > headers.
> > Tom
> You're getting this second-hand since it was my brother who actually
> looked into it, so pardon anything I misremember, but the big problem
> is that adding unicode support to vgacon would need a near total
> rewrite, and nobody wants to do that since it's a terrible hackjob to
> start with.
> kmscon is slated to be the replacement. You might want to see if that
> can do what you need.
I looked kmscon up on Wikipedia, and apparently development ceased
several years ago.
What I have in mind now is writing a Linux driver, a small piece of code
which would piggy-back on the existing virtual terminal drivers, and
simply pass everything through to and from the main driver, filtering out
things relevant to scrolling, and processing these in my new driver.
I've spent the last few evenings reading up on drivers, and reading the
relevant source code from 4.19.97. I can understand the kernel
maintainers not being enthusiastic about the existing code. But that
dates from, I believe, the 1990s, when RAM was measured in megabytes, and
processor speeds in megahertz. Optimisation for speed and store usage
just isn't important any more.
> LMP
--
Alan Mackenzie (Nuremberg, Germany).
