* Re: fbcon: remove soft scrollback code (missing Doc. patch) [not found] <git-mailbomb-linux-master-50145474f6ef4a9c19205b173da6264a644c7489@kernel.org> @ 2020-09-15 1:18 ` Randy Dunlap 2020-09-15 1:28 ` Bhaskar Chowdhury 2020-09-15 1:28 ` Linus Torvalds 0 siblings, 2 replies; 23+ messages in thread From: Randy Dunlap @ 2020-09-15 1:18 UTC (permalink / raw) To: Linus Torvalds, LKML, linux-doc Cc: Greg Kroah-Hartman, Daniel Vetter, Yuan Ming, Willy Tarreau, Bartlomiej Zolnierkiewicz, NopNop Nop, 张云海, Andy Lutomirski HI-- On 9/14/20 3:48 PM, Linux Kernel Mailing List wrote: > Commit: 50145474f6ef4a9c19205b173da6264a644c7489 > Parent: 856deb866d16e29bd65952e0289066f6078af773 > Refname: refs/heads/master > Web: https://git.kernel.org/torvalds/c/50145474f6ef4a9c19205b173da6264a644c7489 > Author: Linus Torvalds <torvalds@linux-foundation.org> > AuthorDate: Mon Sep 7 11:45:27 2020 -0700 > Committer: Linus Torvalds <torvalds@linux-foundation.org> > CommitDate: Mon Sep 14 10:06:15 2020 -0700 > > fbcon: remove soft scrollback code > > This (and the VGA soft scrollback) turns out to have various nasty small > special cases that nobody really is willing to fight. The soft > scrollback code was really useful a few decades ago when you typically > used the console interactively as the main way to interact with the > machine, but that just isn't the case any more. and: > Commit: 973c096f6a85e5b5f2a295126ba6928d9a6afd45 > Parent: 06a0df4d1b8b13b551668e47b11fd7629033b7df > Refname: refs/heads/master > Web: https://git.kernel.org/torvalds/c/973c096f6a85e5b5f2a295126ba6928d9a6afd45 > Author: Linus Torvalds <torvalds@linux-foundation.org> > AuthorDate: Wed Sep 9 14:53:50 2020 -0700 > Committer: Linus Torvalds <torvalds@linux-foundation.org> > CommitDate: Mon Sep 14 10:06:15 2020 -0700 > > vgacon: remove software scrollback support diffstats: > --- > drivers/video/fbdev/core/fbcon.c | 334 +-------------------------------------- > 1 file changed, 4 insertions(+), 330 deletions(-) > arch/powerpc/configs/pasemi_defconfig | 1 - > arch/powerpc/configs/ppc6xx_defconfig | 1 - > arch/x86/configs/i386_defconfig | 1 - > arch/x86/configs/x86_64_defconfig | 1 - > drivers/video/console/Kconfig | 46 ------- > drivers/video/console/vgacon.c | 221 +--------------------------------- > 6 files changed, 1 insertion(+), 270 deletions(-) Now someone can remove the documentation for scrollback (and "no-scroll")... -- ~Randy ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: fbcon: remove soft scrollback code (missing Doc. patch) 2020-09-15 1:18 ` fbcon: remove soft scrollback code (missing Doc. patch) Randy Dunlap @ 2020-09-15 1:28 ` Bhaskar Chowdhury 2020-09-15 1:30 ` Linus Torvalds 2020-09-15 1:34 ` Randy Dunlap 2020-09-15 1:28 ` Linus Torvalds 1 sibling, 2 replies; 23+ messages in thread From: Bhaskar Chowdhury @ 2020-09-15 1:28 UTC (permalink / raw) To: Randy Dunlap Cc: Linus Torvalds, LKML, linux-doc, Greg Kroah-Hartman, Daniel Vetter, Yuan Ming, Willy Tarreau, Bartlomiej Zolnierkiewicz, NopNop Nop, 张云海, Andy Lutomirski, Jonathan Corbet [-- Attachment #1: Type: text/plain, Size: 2851 bytes --] On 18:18 Mon 14 Sep 2020, Randy Dunlap wrote: >HI-- > >On 9/14/20 3:48 PM, Linux Kernel Mailing List wrote: >> Commit: 50145474f6ef4a9c19205b173da6264a644c7489 >> Parent: 856deb866d16e29bd65952e0289066f6078af773 >> Refname: refs/heads/master >> Web: https://git.kernel.org/torvalds/c/50145474f6ef4a9c19205b173da6264a644c7489 >> Author: Linus Torvalds <torvalds@linux-foundation.org> >> AuthorDate: Mon Sep 7 11:45:27 2020 -0700 >> Committer: Linus Torvalds <torvalds@linux-foundation.org> >> CommitDate: Mon Sep 14 10:06:15 2020 -0700 >> >> fbcon: remove soft scrollback code >> >> This (and the VGA soft scrollback) turns out to have various nasty small >> special cases that nobody really is willing to fight. The soft >> scrollback code was really useful a few decades ago when you typically >> used the console interactively as the main way to interact with the >> machine, but that just isn't the case any more. > >and: > >> Commit: 973c096f6a85e5b5f2a295126ba6928d9a6afd45 >> Parent: 06a0df4d1b8b13b551668e47b11fd7629033b7df >> Refname: refs/heads/master >> Web: https://git.kernel.org/torvalds/c/973c096f6a85e5b5f2a295126ba6928d9a6afd45 >> Author: Linus Torvalds <torvalds@linux-foundation.org> >> AuthorDate: Wed Sep 9 14:53:50 2020 -0700 >> Committer: Linus Torvalds <torvalds@linux-foundation.org> >> CommitDate: Mon Sep 14 10:06:15 2020 -0700 >> >> vgacon: remove software scrollback support > > > >diffstats: > >> --- >> drivers/video/fbdev/core/fbcon.c | 334 +-------------------------------------- >> 1 file changed, 4 insertions(+), 330 deletions(-) > >> arch/powerpc/configs/pasemi_defconfig | 1 - >> arch/powerpc/configs/ppc6xx_defconfig | 1 - >> arch/x86/configs/i386_defconfig | 1 - >> arch/x86/configs/x86_64_defconfig | 1 - >> drivers/video/console/Kconfig | 46 ------- >> drivers/video/console/vgacon.c | 221 +--------------------------------- >> 6 files changed, 1 insertion(+), 270 deletions(-) > > > > >Now someone can remove the documentation for scrollback (and "no-scroll")... > > If you wont mind ...let me stab at it ... Documentation/admin-guide/kernel-parameters.txt: no-scroll [VGA] Disables scrollback. Documentation/fb/fbcon.rst:2. fbcon=scrollback:<value>[k] Documentation/fb/fbcon.rst: The scrollback buffer is memory that is used to preserve display Documentation/fb/matroxfb.rst: with 'video=scrollback:0'. Documentation/fb/sstfb.rst: disable software scrollback, as it can oops badly ... Documentation/fb/vesafb.rst: * You'll get scrollback (the Shift-PgUp thing), Documentation/fb/vesafb.rst: the video memory can be used as scrollback buffer ~Bhaskar >-- >~Randy > [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: fbcon: remove soft scrollback code (missing Doc. patch) 2020-09-15 1:28 ` Bhaskar Chowdhury @ 2020-09-15 1:30 ` Linus Torvalds 2020-09-15 1:34 ` Randy Dunlap 1 sibling, 0 replies; 23+ messages in thread From: Linus Torvalds @ 2020-09-15 1:30 UTC (permalink / raw) To: Bhaskar Chowdhury, Randy Dunlap, Linus Torvalds, LKML, linux-doc, Greg Kroah-Hartman, Daniel Vetter, Yuan Ming, Willy Tarreau, Bartlomiej Zolnierkiewicz, NopNop Nop, 张云海, Andy Lutomirski, Jonathan Corbet On Mon, Sep 14, 2020 at 6:28 PM Bhaskar Chowdhury <unixbhaskar@gmail.com> wrote: > > Documentation/admin-guide/kernel-parameters.txt: no-scroll [VGA] Disables scrollback. So this one at least should be still valid. But these: > Documentation/fb/fbcon.rst:2. fbcon=scrollback:<value>[k] > Documentation/fb/fbcon.rst: The scrollback buffer is memory that is used to preserve display > Documentation/fb/matroxfb.rst: with 'video=scrollback:0'. > Documentation/fb/sstfb.rst: disable software scrollback, as it can oops badly ... > Documentation/fb/vesafb.rst: * You'll get scrollback (the Shift-PgUp thing), > Documentation/fb/vesafb.rst: the video memory can be used as scrollback buffer now look stale. Linus ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: fbcon: remove soft scrollback code (missing Doc. patch) 2020-09-15 1:28 ` Bhaskar Chowdhury 2020-09-15 1:30 ` Linus Torvalds @ 2020-09-15 1:34 ` Randy Dunlap 1 sibling, 0 replies; 23+ messages in thread From: Randy Dunlap @ 2020-09-15 1:34 UTC (permalink / raw) To: Bhaskar Chowdhury, Linus Torvalds, LKML, linux-doc, Greg Kroah-Hartman, Daniel Vetter, Yuan Ming, Willy Tarreau, Bartlomiej Zolnierkiewicz, NopNop Nop, 张云海, Andy Lutomirski, Jonathan Corbet On 9/14/20 6:28 PM, Bhaskar Chowdhury wrote: > On 18:18 Mon 14 Sep 2020, Randy Dunlap wrote: >> HI-- >> >> On 9/14/20 3:48 PM, Linux Kernel Mailing List wrote: >>> Commit: 50145474f6ef4a9c19205b173da6264a644c7489 >>> Parent: 856deb866d16e29bd65952e0289066f6078af773 >>> Refname: refs/heads/master >>> Web: https://git.kernel.org/torvalds/c/50145474f6ef4a9c19205b173da6264a644c7489 >>> Author: Linus Torvalds <torvalds@linux-foundation.org> >>> AuthorDate: Mon Sep 7 11:45:27 2020 -0700 >>> Committer: Linus Torvalds <torvalds@linux-foundation.org> >>> CommitDate: Mon Sep 14 10:06:15 2020 -0700 >>> >>> fbcon: remove soft scrollback code >>> This (and the VGA soft scrollback) turns out to have various nasty small >>> special cases that nobody really is willing to fight. The soft >>> scrollback code was really useful a few decades ago when you typically >>> used the console interactively as the main way to interact with the >>> machine, but that just isn't the case any more. >> >> and: >> >>> Commit: 973c096f6a85e5b5f2a295126ba6928d9a6afd45 >>> Parent: 06a0df4d1b8b13b551668e47b11fd7629033b7df >>> Refname: refs/heads/master >>> Web: https://git.kernel.org/torvalds/c/973c096f6a85e5b5f2a295126ba6928d9a6afd45 >>> Author: Linus Torvalds <torvalds@linux-foundation.org> >>> AuthorDate: Wed Sep 9 14:53:50 2020 -0700 >>> Committer: Linus Torvalds <torvalds@linux-foundation.org> >>> CommitDate: Mon Sep 14 10:06:15 2020 -0700 >>> >>> vgacon: remove software scrollback support >> >> >> >> diffstats: >> >>> --- >>> drivers/video/fbdev/core/fbcon.c | 334 +-------------------------------------- >>> 1 file changed, 4 insertions(+), 330 deletions(-) >> >>> arch/powerpc/configs/pasemi_defconfig | 1 - >>> arch/powerpc/configs/ppc6xx_defconfig | 1 - >>> arch/x86/configs/i386_defconfig | 1 - >>> arch/x86/configs/x86_64_defconfig | 1 - >>> drivers/video/console/Kconfig | 46 ------- >>> drivers/video/console/vgacon.c | 221 +--------------------------------- >>> 6 files changed, 1 insertion(+), 270 deletions(-) >> >> >> >> >> Now someone can remove the documentation for scrollback (and "no-scroll")... >> >> > If you wont mind ...let me stab at it ... Sure, go for it. Thanks. > > Documentation/admin-guide/kernel-parameters.txt: no-scroll [VGA] Disables scrollback. > Documentation/fb/fbcon.rst:2. fbcon=scrollback:<value>[k] > Documentation/fb/fbcon.rst: The scrollback buffer is memory that is used to preserve display > Documentation/fb/matroxfb.rst: with 'video=scrollback:0'. > Documentation/fb/sstfb.rst: disable software scrollback, as it can oops badly ... > Documentation/fb/vesafb.rst: * You'll get scrollback (the Shift-PgUp thing), > Documentation/fb/vesafb.rst: the video memory can be used as scrollback buffer -- ~Randy ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: fbcon: remove soft scrollback code (missing Doc. patch) 2020-09-15 1:18 ` fbcon: remove soft scrollback code (missing Doc. patch) Randy Dunlap 2020-09-15 1:28 ` Bhaskar Chowdhury @ 2020-09-15 1:28 ` Linus Torvalds 2020-09-16 20:54 ` Pavel Machek 1 sibling, 1 reply; 23+ messages in thread From: Linus Torvalds @ 2020-09-15 1:28 UTC (permalink / raw) To: Randy Dunlap Cc: LKML, linux-doc, Greg Kroah-Hartman, Daniel Vetter, Yuan Ming, Willy Tarreau, Bartlomiej Zolnierkiewicz, NopNop Nop, 张云海, Andy Lutomirski On Mon, Sep 14, 2020 at 6:19 PM Randy Dunlap <rdunlap@infradead.org> wrote: > > Now someone can remove the documentation for scrollback (and "no-scroll")... Note that scrollback hasn't actually gone away entirely - the original scrollback supported by _hardware_ still exists. Of course, that's really just the old-fashioned text VGA console, but that one actually scrolls not by moving any bytes around, but by moving the screen start address. And the scrollback similarly isn't about any software buffering, but about the ability of moving back that screen start address. Do people use that? Probably not. But it wasn't removed because it didn't have any of the complexities and bitrot that all the software buffering code had. That said, I didn't check how much of the documentation is for the VGA text console, and how much of it is for the actual software scrollback for fbcon etc. So it is entirely possible that all the docs are about the removed parts. Linus ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: fbcon: remove soft scrollback code (missing Doc. patch) 2020-09-15 1:28 ` Linus Torvalds @ 2020-09-16 20:54 ` Pavel Machek 2020-09-18 10:27 ` Adam Borowski 2021-01-08 19:01 ` Phillip Susi 0 siblings, 2 replies; 23+ messages in thread From: Pavel Machek @ 2020-09-16 20:54 UTC (permalink / raw) To: Linus Torvalds Cc: Randy Dunlap, LKML, linux-doc, Greg Kroah-Hartman, Daniel Vetter, Yuan Ming, Willy Tarreau, Bartlomiej Zolnierkiewicz, NopNop Nop, 张云海, Andy Lutomirski [-- Attachment #1: Type: text/plain, Size: 1972 bytes --] On Mon 2020-09-14 18:28:34, Linus Torvalds wrote: > On Mon, Sep 14, 2020 at 6:19 PM Randy Dunlap <rdunlap@infradead.org> wrote: > > > > Now someone can remove the documentation for scrollback (and "no-scroll")... > > Note that scrollback hasn't actually gone away entirely - the original > scrollback supported by _hardware_ still exists. > > Of course, that's really just the old-fashioned text VGA console, but > that one actually scrolls not by moving any bytes around, but by > moving the screen start address. And the scrollback similarly isn't > about any software buffering, but about the ability of moving back > that screen start address. > > Do people use that? Probably not. But it wasn't removed because it > didn't have any of the complexities and bitrot that all the software > buffering code had. > > That said, I didn't check how much of the documentation is for the VGA > text console, and how much of it is for the actual software scrollback > for fbcon etc. So it is entirely possible that all the docs are about > the removed parts. Could we pause this madness? Scrollback is still useful. I needed it today... it was too small, so command results I was looking for already scrolled away, but... life will be really painful with 0 scrollback. You'll need it, too... as soon as you get oops and will want to see errors just prior to that oops. If it means I get to maintain it... I'm not happy about it but that's better than no scrollback. Kernel is now very verbose, so important messages during bootup scroll away. It is way bigger deal when you can no longer get to them using shift-pageup. fsck is rather verbose, too, and there's no easy way to run that under X terminal... and yes, that makes scrollback very useful, too. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: fbcon: remove soft scrollback code (missing Doc. patch) 2020-09-16 20:54 ` Pavel Machek @ 2020-09-18 10:27 ` Adam Borowski 2020-09-30 21:29 ` Maciej W. Rozycki 2021-01-08 19:01 ` Phillip Susi 1 sibling, 1 reply; 23+ messages in thread From: Adam Borowski @ 2020-09-18 10:27 UTC (permalink / raw) To: Pavel Machek Cc: Linus Torvalds, Randy Dunlap, LKML, linux-doc, Greg Kroah-Hartman, Daniel Vetter, Yuan Ming, Willy Tarreau, Bartlomiej Zolnierkiewicz, NopNop Nop, 张云海, Andy Lutomirski On Wed, Sep 16, 2020 at 10:54:34PM +0200, Pavel Machek wrote: > On Mon 2020-09-14 18:28:34, Linus Torvalds wrote: > > Note that scrollback hasn't actually gone away entirely - the original > > scrollback supported by _hardware_ still exists. > > > > Of course, that's really just the old-fashioned text VGA console, but > > that one actually scrolls not by moving any bytes around, but by > > moving the screen start address. And the scrollback similarly isn't > > about any software buffering, but about the ability of moving back > > that screen start address. > Could we pause this madness? Scrollback is still useful. I needed it > today... it was too small, so command results I was looking for > already scrolled away, but... life will be really painful with 0 scrollback. > > You'll need it, too... as soon as you get oops and will want to see > errors just prior to that oops. I concur -- this a serious usability regression for regular users. Linus: you have a serial cable on your main dev machine, so do I, but hardly any regular people do -- that's restricted to mostly IPMI and such. And without some kind of scrollback, there's no way of knowing why eg. your rootfs failed to mount (there was some oops, but its reason was at the beginning...). Or, any other problem the user would be able to solve, or pass the error messages to someone more knowledgeable. I also wonder why did you choose to remove softscrollback which is actually useful, yet leave hardscrollback which doesn't come to use on any non-ancient hardware: * on !x86 there's no vgacon at all * on x86, in-tree drivers for GPUs by Intel, nVidia and AMD (others are dead) default to switching away from vgacon * EFI wants its own earlycon ... thus, the only niche left is nVidia proprietary drivers which, the last time I looked, still used CGA text mode. > If it means I get to maintain it... I'm not happy about it but that's > better than no scrollback. That'd be greatly appreciated. There are also some simplifications/rewrites that could be done, like getting rid of redundant 1-byte/4-byte storage (or even the code for 1-byte...). Hard scrollback could be axed altogether (it provides only a small amount of scroll). Etc... > Kernel is now very verbose, so important messages > during bootup scroll away. It is way bigger deal when you can no > longer get to them using shift-pageup. Thus hard scrollback is inadequate in the rare cases it's even present. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- <willmore> on #linux-sunxi ⠈⠳⣄⠀⠀⠀⠀ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: fbcon: remove soft scrollback code (missing Doc. patch) 2020-09-18 10:27 ` Adam Borowski @ 2020-09-30 21:29 ` Maciej W. Rozycki 0 siblings, 0 replies; 23+ messages in thread From: Maciej W. Rozycki @ 2020-09-30 21:29 UTC (permalink / raw) To: Adam Borowski Cc: Pavel Machek, Linus Torvalds, Randy Dunlap, LKML, linux-doc, Greg Kroah-Hartman, Daniel Vetter, Yuan Ming, Willy Tarreau, Bartlomiej Zolnierkiewicz, NopNop Nop, 张云海, Andy Lutomirski On Fri, 18 Sep 2020, Adam Borowski wrote: > > > Note that scrollback hasn't actually gone away entirely - the original > > > scrollback supported by _hardware_ still exists. > > > > > > Of course, that's really just the old-fashioned text VGA console, but > > > that one actually scrolls not by moving any bytes around, but by > > > moving the screen start address. And the scrollback similarly isn't > > > about any software buffering, but about the ability of moving back > > > that screen start address. > > > Could we pause this madness? Scrollback is still useful. I needed it > > today... it was too small, so command results I was looking for > > already scrolled away, but... life will be really painful with 0 scrollback. > > > > You'll need it, too... as soon as you get oops and will want to see > > errors just prior to that oops. > > I concur -- this a serious usability regression for regular users. Linus: > you have a serial cable on your main dev machine, so do I, but hardly any > regular people do -- that's restricted to mostly IPMI and such. > > And without some kind of scrollback, there's no way of knowing why eg. > your rootfs failed to mount (there was some oops, but its reason was at > the beginning...). Or, any other problem the user would be able to solve, > or pass the error messages to someone more knowledgeable. > > I also wonder why did you choose to remove softscrollback which is actually > useful, yet leave hardscrollback which doesn't come to use on any > non-ancient hardware: > * on !x86 there's no vgacon at all > * on x86, in-tree drivers for GPUs by Intel, nVidia and AMD (others are > dead) default to switching away from vgacon > * EFI wants its own earlycon > ... thus, the only niche left is nVidia proprietary drivers which, the last > time I looked, still used CGA text mode. For the record I keep using the console scrollback all the time, and FWIW I have gone through all the hoops required to keep using VGA hardware emulation and its console text mode with my most recent laptop, which is a ThinkPad P51; no longer manufactured, but still hardly an obsolete device by today's standards I believe. Sadly this video adapter setup has its shortcomings which used not to be there with my older hardware, which I find a functional regression to be blamed on the manufacturer, but I have learnt to live with that as I found no alternative I would find comfortable to work with. So no, it's not that nobody uses that stuff anymore, and not with obsolete hardware either. Maciej ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: fbcon: remove soft scrollback code (missing Doc. patch) 2020-09-16 20:54 ` Pavel Machek 2020-09-18 10:27 ` Adam Borowski @ 2021-01-08 19:01 ` Phillip Susi 2021-01-08 23:11 ` Linus Torvalds 1 sibling, 1 reply; 23+ messages in thread From: Phillip Susi @ 2021-01-08 19:01 UTC (permalink / raw) To: Pavel Machek Cc: Linus Torvalds, Randy Dunlap, LKML, linux-doc, Greg Kroah-Hartman, Daniel Vetter > Could we pause this madness? Scrollback is still useful. I needed it > today... it was too small, so command results I was looking for > already scrolled away, but... life will be really painful with 0 > scrollback. > You'll need it, too... as soon as you get oops and will want to see > errors just prior to that oops. > If it means I get to maintain it... I'm not happy about it but that's > better than no scrollback. Amen! What self respecting admin installs a gui on servers? What do we have to do to get this back in? What was so buggy with this code that it needed to be removed? Why was it such a burden to just leave it be? Now excuse me while I go dust off the old ext2 defrag utility and enjoy watching disk blocks move around the ncurses interface. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: fbcon: remove soft scrollback code (missing Doc. patch) 2021-01-08 19:01 ` Phillip Susi @ 2021-01-08 23:11 ` Linus Torvalds 2021-01-12 15:00 ` Phillip Susi ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: Linus Torvalds @ 2021-01-08 23:11 UTC (permalink / raw) To: Phillip Susi Cc: Pavel Machek, Randy Dunlap, LKML, linux-doc, Greg Kroah-Hartman, Daniel Vetter On Fri, Jan 8, 2021 at 11:13 AM Phillip Susi <phill@thesusis.net> wrote: > > > Could we pause this madness? Scrollback is still useful. I needed it > > today... it was too small, so command results I was looking for > > already scrolled away, but... life will be really painful with 0 > > scrollback. > > > You'll need it, too... as soon as you get oops and will want to see > > errors just prior to that oops. > > > If it means I get to maintain it... I'm not happy about it but that's > > better than no scrollback. > > Amen! What self respecting admin installs a gui on servers? What do we > have to do to get this back in? What was so buggy with this code that > it needed to be removed? Why was it such a burden to just leave it be? It really was buggy, with security implications. And we have no maintainers. So the scroll-back code can't come back until we have a maintainer and a cleaner and simpler implementation. And no, maintaining it really doesn't mean "just get it back to the old broken state". So far I haven't actually seen any patches, which means that it's not coming back. The good news? If you have an actual text VGA console, that should still work just fine. Linus ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: fbcon: remove soft scrollback code (missing Doc. patch) 2021-01-08 23:11 ` Linus Torvalds @ 2021-01-12 15:00 ` Phillip Susi 2021-01-12 16:11 ` Greg Kroah-Hartman 2021-01-12 15:57 ` Daniel Vetter 2021-01-14 17:43 ` fbcon: remove soft scrollback code Alan Mackenzie 2 siblings, 1 reply; 23+ messages in thread From: Phillip Susi @ 2021-01-12 15:00 UTC (permalink / raw) To: Linus Torvalds Cc: Pavel Machek, Randy Dunlap, LKML, linux-doc, Greg Kroah-Hartman, Daniel Vetter Linus Torvalds writes: > It really was buggy, with security implications. And we have no maintainers. Could you be more specific? I can't try to fix it if I don't understand what is wrong with it. Are there any bug reports or anything I could look at? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: fbcon: remove soft scrollback code (missing Doc. patch) 2021-01-12 15:00 ` Phillip Susi @ 2021-01-12 16:11 ` Greg Kroah-Hartman 0 siblings, 0 replies; 23+ messages in thread From: Greg Kroah-Hartman @ 2021-01-12 16:11 UTC (permalink / raw) To: Phillip Susi Cc: Linus Torvalds, Pavel Machek, Randy Dunlap, LKML, linux-doc, Daniel Vetter On Tue, Jan 12, 2021 at 10:00:09AM -0500, Phillip Susi wrote: > > Linus Torvalds writes: > > > It really was buggy, with security implications. And we have no maintainers. > > Could you be more specific? I can't try to fix it if I don't understand > what is wrong with it. Are there any bug reports or anything I could > look at? Along with what Daniel has already pointed out, just look at all of the old syzbot reports for the code in this area. Try fixing one of those reports in an older kernel to give yourself an idea of the issues involved. Best of luck! greg k-h ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: fbcon: remove soft scrollback code (missing Doc. patch) 2021-01-08 23:11 ` Linus Torvalds 2021-01-12 15:00 ` Phillip Susi @ 2021-01-12 15:57 ` Daniel Vetter 2021-01-14 15:56 ` Geert Uytterhoeven 2021-01-14 17:43 ` fbcon: remove soft scrollback code Alan Mackenzie 2 siblings, 1 reply; 23+ messages in thread From: Daniel Vetter @ 2021-01-12 15:57 UTC (permalink / raw) To: Linus Torvalds Cc: Phillip Susi, Pavel Machek, Randy Dunlap, LKML, linux-doc, Greg Kroah-Hartman, dri-devel On Sat, Jan 9, 2021 at 12:11 AM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Fri, Jan 8, 2021 at 11:13 AM Phillip Susi <phill@thesusis.net> wrote: > > > > > Could we pause this madness? Scrollback is still useful. I needed it > > > today... it was too small, so command results I was looking for > > > already scrolled away, but... life will be really painful with 0 > > > scrollback. > > > > > You'll need it, too... as soon as you get oops and will want to see > > > errors just prior to that oops. > > > > > If it means I get to maintain it... I'm not happy about it but that's > > > better than no scrollback. > > > > Amen! What self respecting admin installs a gui on servers? What do we > > have to do to get this back in? What was so buggy with this code that > > it needed to be removed? Why was it such a burden to just leave it be? > > It really was buggy, with security implications. And we have no maintainers. > > So the scroll-back code can't come back until we have a maintainer and > a cleaner and simpler implementation. > > And no, maintaining it really doesn't mean "just get it back to the > old broken state". > > So far I haven't actually seen any patches, which means that it's not > coming back. > > The good news? If you have an actual text VGA console, that should > still work just fine. Also on anything that is remotely modern (i.e. runs a drm kernel modesetting driver undearneath the fbdev/fbcon stack) there's a pile more issues on top of just the scrollback/fbcon code being a mess. Specifically the locking is somewhere between yolo and outright deadlocks. This holds even more so if the use case here is "I want scrollback for an oops". There's rough sketches for how it could be solved, but it's all very tricky work. Also, we need testcases for this, both in-kernel unit-test style stuff and uapi testcases. Especially the full interaction on a modern stack between /dev/fb/0, /dev/drm/card0, vt ioctls and the console is a pure nightmare. Altogether this is a few years of full time hacking to get this back into shape, and until that's happening and clearly getting somewhere the only reasonable thing to do is to delete features in response to syzkaller crashes. Also adding dri-devel since defacto that's the only place where display people hang out nowadays. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: fbcon: remove soft scrollback code (missing Doc. patch) 2021-01-12 15:57 ` Daniel Vetter @ 2021-01-14 15:56 ` Geert Uytterhoeven 2021-01-14 16:11 ` Daniel Vetter 2021-01-22 18:55 ` Phillip Susi 0 siblings, 2 replies; 23+ messages in thread From: Geert Uytterhoeven @ 2021-01-14 15:56 UTC (permalink / raw) To: Daniel Vetter Cc: Linus Torvalds, Phillip Susi, Pavel Machek, Randy Dunlap, LKML, linux-doc, Greg Kroah-Hartman, dri-devel, Linux Fbdev development list Hi Daniel, CC linux-fbdev On Tue, Jan 12, 2021 at 5:00 PM Daniel Vetter <daniel@ffwll.ch> wrote: > On Sat, Jan 9, 2021 at 12:11 AM Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > On Fri, Jan 8, 2021 at 11:13 AM Phillip Susi <phill@thesusis.net> wrote: > > > > Could we pause this madness? Scrollback is still useful. I needed it > > > > today... it was too small, so command results I was looking for > > > > already scrolled away, but... life will be really painful with 0 > > > > scrollback. > > > > > > > You'll need it, too... as soon as you get oops and will want to see > > > > errors just prior to that oops. > > > > > > > If it means I get to maintain it... I'm not happy about it but that's > > > > better than no scrollback. > > > > > > Amen! What self respecting admin installs a gui on servers? What do we > > > have to do to get this back in? What was so buggy with this code that > > > it needed to be removed? Why was it such a burden to just leave it be? > > > > It really was buggy, with security implications. And we have no maintainers. > > > > So the scroll-back code can't come back until we have a maintainer and > > a cleaner and simpler implementation. > > > > And no, maintaining it really doesn't mean "just get it back to the > > old broken state". > > > > So far I haven't actually seen any patches, which means that it's not > > coming back. > > > > The good news? If you have an actual text VGA console, that should > > still work just fine. IIRC, all of this was written for systems lacking VGA text consoles in the first place... > Also on anything that is remotely modern (i.e. runs a drm kernel > modesetting driver undearneath the fbdev/fbcon stack) there's a pile > more issues on top of just the scrollback/fbcon code being a mess. Would it help to remove DRM_FBDEV_EMULATION (instead)? > Specifically the locking is somewhere between yolo and outright > deadlocks. This holds even more so if the use case here is "I want > scrollback for an oops". There's rough sketches for how it could be > solved, but it's all very tricky work. When an oops happens, all bets are off. At that point, all information you can extract from the system is valuable, and additional locking issues are moot. > Also adding dri-devel since defacto that's the only place where > display people hang out nowadays. Please keep on CCing linux-fbdev, especially for patches removing fbdev features. Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: fbcon: remove soft scrollback code (missing Doc. patch) 2021-01-14 15:56 ` Geert Uytterhoeven @ 2021-01-14 16:11 ` Daniel Vetter 2021-01-15 8:06 ` Geert Uytterhoeven 2021-01-22 18:55 ` Phillip Susi 1 sibling, 1 reply; 23+ messages in thread From: Daniel Vetter @ 2021-01-14 16:11 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Linus Torvalds, Phillip Susi, Pavel Machek, Randy Dunlap, LKML, linux-doc, Greg Kroah-Hartman, dri-devel, Linux Fbdev development list On Thu, Jan 14, 2021 at 4:56 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Daniel, > > CC linux-fbdev > > On Tue, Jan 12, 2021 at 5:00 PM Daniel Vetter <daniel@ffwll.ch> wrote: > > On Sat, Jan 9, 2021 at 12:11 AM Linus Torvalds > > <torvalds@linux-foundation.org> wrote: > > > On Fri, Jan 8, 2021 at 11:13 AM Phillip Susi <phill@thesusis.net> wrote: > > > > > Could we pause this madness? Scrollback is still useful. I needed it > > > > > today... it was too small, so command results I was looking for > > > > > already scrolled away, but... life will be really painful with 0 > > > > > scrollback. > > > > > > > > > You'll need it, too... as soon as you get oops and will want to see > > > > > errors just prior to that oops. > > > > > > > > > If it means I get to maintain it... I'm not happy about it but that's > > > > > better than no scrollback. > > > > > > > > Amen! What self respecting admin installs a gui on servers? What do we > > > > have to do to get this back in? What was so buggy with this code that > > > > it needed to be removed? Why was it such a burden to just leave it be? > > > > > > It really was buggy, with security implications. And we have no maintainers. > > > > > > So the scroll-back code can't come back until we have a maintainer and > > > a cleaner and simpler implementation. > > > > > > And no, maintaining it really doesn't mean "just get it back to the > > > old broken state". > > > > > > So far I haven't actually seen any patches, which means that it's not > > > coming back. > > > > > > The good news? If you have an actual text VGA console, that should > > > still work just fine. > > IIRC, all of this was written for systems lacking VGA text consoles > in the first place... > > > Also on anything that is remotely modern (i.e. runs a drm kernel > > modesetting driver undearneath the fbdev/fbcon stack) there's a pile > > more issues on top of just the scrollback/fbcon code being a mess. > > Would it help to remove DRM_FBDEV_EMULATION (instead)? It's a problem with the hardware. "Write some registers and done" isn't how display blocks work nowadays. So your proposal amounts to "no fbdev/fbcon for anything modern-ish". Also I said "a pile more", most of the issues in fbcon/fbdev code apply for all drivers. > > Specifically the locking is somewhere between yolo and outright > > deadlocks. This holds even more so if the use case here is "I want > > scrollback for an oops". There's rough sketches for how it could be > > solved, but it's all very tricky work. > > When an oops happens, all bets are off. At that point, all information > you can extract from the system is valuable, and additional locking > issues are moot. Except the first oops then scrolls aways because it's getting buried under further fail. Your locking needs to be minimally good enough to not make the situation worse. -Daniel > > Also adding dri-devel since defacto that's the only place where > > display people hang out nowadays. > > Please keep on CCing linux-fbdev, especially for patches removing > fbdev features. > > Thanks! > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: fbcon: remove soft scrollback code (missing Doc. patch) 2021-01-14 16:11 ` Daniel Vetter @ 2021-01-15 8:06 ` Geert Uytterhoeven 2021-02-03 8:03 ` Thomas Zimmermann 0 siblings, 1 reply; 23+ messages in thread From: Geert Uytterhoeven @ 2021-01-15 8:06 UTC (permalink / raw) To: Daniel Vetter Cc: Linus Torvalds, Phillip Susi, Pavel Machek, Randy Dunlap, LKML, linux-doc, Greg Kroah-Hartman, dri-devel, Linux Fbdev development list Hi Daniel, On Thu, Jan 14, 2021 at 5:11 PM Daniel Vetter <daniel@ffwll.ch> wrote: > On Thu, Jan 14, 2021 at 4:56 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > On Tue, Jan 12, 2021 at 5:00 PM Daniel Vetter <daniel@ffwll.ch> wrote: > > > On Sat, Jan 9, 2021 at 12:11 AM Linus Torvalds > > > <torvalds@linux-foundation.org> wrote: > > > > On Fri, Jan 8, 2021 at 11:13 AM Phillip Susi <phill@thesusis.net> wrote: > > > > > > Could we pause this madness? Scrollback is still useful. I needed it > > > > > > today... it was too small, so command results I was looking for > > > > > > already scrolled away, but... life will be really painful with 0 > > > > > > scrollback. > > > > > > > > > > > You'll need it, too... as soon as you get oops and will want to see > > > > > > errors just prior to that oops. > > > > > > > > > > > If it means I get to maintain it... I'm not happy about it but that's > > > > > > better than no scrollback. > > > > > > > > > > Amen! What self respecting admin installs a gui on servers? What do we > > > > > have to do to get this back in? What was so buggy with this code that > > > > > it needed to be removed? Why was it such a burden to just leave it be? > > > > > > > > It really was buggy, with security implications. And we have no maintainers. > > > > > > > > So the scroll-back code can't come back until we have a maintainer and > > > > a cleaner and simpler implementation. > > > > > > > > And no, maintaining it really doesn't mean "just get it back to the > > > > old broken state". > > > > > > > > So far I haven't actually seen any patches, which means that it's not > > > > coming back. > > > > > > > > The good news? If you have an actual text VGA console, that should > > > > still work just fine. > > > > IIRC, all of this was written for systems lacking VGA text consoles > > in the first place... > > > > > Also on anything that is remotely modern (i.e. runs a drm kernel > > > modesetting driver undearneath the fbdev/fbcon stack) there's a pile > > > more issues on top of just the scrollback/fbcon code being a mess. > > > > Would it help to remove DRM_FBDEV_EMULATION (instead)? > > It's a problem with the hardware. "Write some registers and done" > isn't how display blocks work nowadays. So your proposal amounts to > "no fbdev/fbcon for anything modern-ish". With "modern-ish" actually meaning: "desktop/gaming/mobile-style 3D-accelerated wide-color display hardware". There's plenty of display hardware that doesn't fall into that class, and is served by fbdev (also out-of-tree due to the moratorium) because of that. > Also I said "a pile more", most of the issues in fbcon/fbdev code > apply for all drivers. > > > > Specifically the locking is somewhere between yolo and outright > > > deadlocks. This holds even more so if the use case here is "I want > > > scrollback for an oops". There's rough sketches for how it could be > > > solved, but it's all very tricky work. > > > > When an oops happens, all bets are off. At that point, all information > > you can extract from the system is valuable, and additional locking > > issues are moot. > > Except the first oops then scrolls aways because it's getting buried > under further fail. Your locking needs to be minimally good enough to > not make the situation worse. When an oops happens, all bets are off... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: fbcon: remove soft scrollback code (missing Doc. patch) 2021-01-15 8:06 ` Geert Uytterhoeven @ 2021-02-03 8:03 ` Thomas Zimmermann 0 siblings, 0 replies; 23+ messages in thread From: Thomas Zimmermann @ 2021-02-03 8:03 UTC (permalink / raw) To: Geert Uytterhoeven, Daniel Vetter Cc: Linus Torvalds, Phillip Susi, Pavel Machek, Randy Dunlap, LKML, linux-doc, Greg Kroah-Hartman, dri-devel, Linux Fbdev development list [-- Attachment #1.1: Type: text/plain, Size: 4180 bytes --] Hi Am 15.01.21 um 09:06 schrieb Geert Uytterhoeven: > Hi Daniel, > > On Thu, Jan 14, 2021 at 5:11 PM Daniel Vetter <daniel@ffwll.ch> wrote: >> On Thu, Jan 14, 2021 at 4:56 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: >>> On Tue, Jan 12, 2021 at 5:00 PM Daniel Vetter <daniel@ffwll.ch> wrote: >>>> On Sat, Jan 9, 2021 at 12:11 AM Linus Torvalds >>>> <torvalds@linux-foundation.org> wrote: >>>>> On Fri, Jan 8, 2021 at 11:13 AM Phillip Susi <phill@thesusis.net> wrote: >>>>>>> Could we pause this madness? Scrollback is still useful. I needed it >>>>>>> today... it was too small, so command results I was looking for >>>>>>> already scrolled away, but... life will be really painful with 0 >>>>>>> scrollback. >>>>>> >>>>>>> You'll need it, too... as soon as you get oops and will want to see >>>>>>> errors just prior to that oops. >>>>>> >>>>>>> If it means I get to maintain it... I'm not happy about it but that's >>>>>>> better than no scrollback. >>>>>> >>>>>> Amen! What self respecting admin installs a gui on servers? What do we >>>>>> have to do to get this back in? What was so buggy with this code that >>>>>> it needed to be removed? Why was it such a burden to just leave it be? >>>>> >>>>> It really was buggy, with security implications. And we have no maintainers. >>>>> >>>>> So the scroll-back code can't come back until we have a maintainer and >>>>> a cleaner and simpler implementation. >>>>> >>>>> And no, maintaining it really doesn't mean "just get it back to the >>>>> old broken state". >>>>> >>>>> So far I haven't actually seen any patches, which means that it's not >>>>> coming back. >>>>> >>>>> The good news? If you have an actual text VGA console, that should >>>>> still work just fine. >>> >>> IIRC, all of this was written for systems lacking VGA text consoles >>> in the first place... >>> >>>> Also on anything that is remotely modern (i.e. runs a drm kernel >>>> modesetting driver undearneath the fbdev/fbcon stack) there's a pile >>>> more issues on top of just the scrollback/fbcon code being a mess. >>> >>> Would it help to remove DRM_FBDEV_EMULATION (instead)? Of the fbdev code, DRM's fbdev emulation is the cleanest. We now even have test cases for the userspace I/O. >> >> It's a problem with the hardware. "Write some registers and done" >> isn't how display blocks work nowadays. So your proposal amounts to >> "no fbdev/fbcon for anything modern-ish". > > With "modern-ish" actually meaning: "desktop/gaming/mobile-style > 3D-accelerated wide-color display hardware". There's plenty of display > hardware that doesn't fall into that class, and is served by fbdev (also > out-of-tree due to the moratorium) because of that. Userspace has been moving away from fbdev. Writing an fbdev driver locks you into a legacy userspace. I also found that DRM drivers are smaller, because of all the DRM helper libraries. Using DRM + fbdev emulation is a win in almost any case. We did have some complaints about performance of the emulation. So that might be worth looking into. Best regards Thomas > >> Also I said "a pile more", most of the issues in fbcon/fbdev code >> apply for all drivers. >> >>>> Specifically the locking is somewhere between yolo and outright >>>> deadlocks. This holds even more so if the use case here is "I want >>>> scrollback for an oops". There's rough sketches for how it could be >>>> solved, but it's all very tricky work. >>> >>> When an oops happens, all bets are off. At that point, all information >>> you can extract from the system is valuable, and additional locking >>> issues are moot. >> >> Except the first oops then scrolls aways because it's getting buried >> under further fail. Your locking needs to be minimally good enough to >> not make the situation worse. > > When an oops happens, all bets are off... > > Gr{oetje,eeting}s, > > Geert > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: fbcon: remove soft scrollback code (missing Doc. patch) 2021-01-14 15:56 ` Geert Uytterhoeven 2021-01-14 16:11 ` Daniel Vetter @ 2021-01-22 18:55 ` Phillip Susi 2021-01-25 15:39 ` Geert Uytterhoeven 2021-02-02 14:18 ` Daniel Vetter 1 sibling, 2 replies; 23+ messages in thread From: Phillip Susi @ 2021-01-22 18:55 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Daniel Vetter, Linus Torvalds, Pavel Machek, Randy Dunlap, LKML, linux-doc, Greg Kroah-Hartman, dri-devel, Linux Fbdev development list Geert Uytterhoeven writes: Judging from some of the comments in the code, it looks like you were one of the original authors of fbcon? I haven't been able to find any of these sczbot crash reports, and am not sure how fuzzing syscalls would really affect this code ( it's not really handling a buch of ioctls or otherwise taking arguments from user space ) , but I am a bit confused as to why the softback was implemented the way that it was. vgacon simply copies the main buffer to vram in ->set_origin() and then changes the pointers to operate out of the much larger vram while that virtual terminal is active. If I understand it correctly, it looks like fbcon instead opts to operate out of the main buffer but rescue lines as they are scrolled off and relocate them to the softback buffer. This seems to be rather more convoluted. I'm thinking of re-implementing scrollback more like the way vgacon does it: allocate a big "vram" buffer and operate out of that. Obviously ->scroll() and ->scrolldelta() have to actually repaint the screen rather than simply change the pointer register, but that should be about the only difference. I have also noticed that there was some code to use hardware panning of the video buffer rather than having to do a block bitblt to scroll the contents of the screen, but that it was disabled because virtually no video drivers actually implemented it? That seems like a shame, but if it is so, then there's no sense carrying the dead code so I think I'll clean that up now. Now that I look at it again, everything is simply always redrawn now instead of even doing a simple bitblt. Daniel, you mentioned that almost nobody supports hardware acceleration, but even without any specific hardware support, surely even if bitblt() is implemented just as a memcpy(), it has to be faster than redrawing all of the characters doesn't it? Getting rid of the panning if it isn't generally supported I can see, but I don't understand killing bitblt even if most devices don't accelerate it. In addition, I noticed that ->screen_pos() was changed to just return vc_origin+offset. fbcon is the only console driver to implement ->screenpos() and if not implemented, vt defaults to using vc_visible_origin+offset, so it looks like this function isn't needed at all anymore and ->screen_pos() can be removed from struct consw. Does this make sense or am I talking crazy? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: fbcon: remove soft scrollback code (missing Doc. patch) 2021-01-22 18:55 ` Phillip Susi @ 2021-01-25 15:39 ` Geert Uytterhoeven 2021-02-02 14:18 ` Daniel Vetter 1 sibling, 0 replies; 23+ messages in thread From: Geert Uytterhoeven @ 2021-01-25 15:39 UTC (permalink / raw) To: Phillip Susi Cc: Daniel Vetter, Linus Torvalds, Pavel Machek, Randy Dunlap, LKML, linux-doc, Greg Kroah-Hartman, dri-devel, Linux Fbdev development list Hi Phillip, On Fri, Jan 22, 2021 at 8:26 PM Phillip Susi <phill@thesusis.net> wrote: > Geert Uytterhoeven writes: > Judging from some of the comments in the code, it looks like you were > one of the original authors of fbcon? I haven't been able to find any Indeed, a looooong time ago... Before DRM existed. > of these sczbot crash reports, and am not sure how fuzzing syscalls > would really affect this code ( it's not really handling a buch of > ioctls or otherwise taking arguments from user space ) , but I am a bit AFAIU, most of these are triggered by VT ioctls. There is an intimate relation between the VT and fbev subsystems: VT changes impact fbdev, and vice versa. Perhaps these should be decoupled, at the expense of worse user experience (i.e. the user needing to change both screen resolution and number of columns/rows of the text console)? > confused as to why the softback was implemented the way that it was. > > vgacon simply copies the main buffer to vram in ->set_origin() and then > changes the pointers to operate out of the much larger vram while that > virtual terminal is active. If I understand it correctly, it looks like > fbcon instead opts to operate out of the main buffer but rescue lines as > they are scrolled off and relocate them to the softback buffer. This > seems to be rather more convoluted. > > I'm thinking of re-implementing scrollback more like the way vgacon does > it: allocate a big "vram" buffer and operate out of that. Obviously > ->scroll() and ->scrolldelta() have to actually repaint the screen rather > than simply change the pointer register, but that should be about the > only difference. I'm not that intimate familiar anymore with the current state of the code, but it used to be like this: - vgacon used a VRAM buffer for the current VC, and multiple shadow buffers to implement virtual consoles, - fbcon always used the shadow buffers, with each update triggering an update of the frame buffer (see below). As the text console buffer handling should be the same for vgacon and fbcon, I expect most scrollback bugs (if any) to be present in both. > I have also noticed that there was some code to use hardware panning of > the video buffer rather than having to do a block bitblt to scroll the > contents of the screen, but that it was disabled because virtually no > video drivers actually implemented it? That seems like a shame, but if > it is so, then there's no sense carrying the dead code so I think I'll > clean that up now. > > Now that I look at it again, everything is simply always redrawn now > instead of even doing a simple bitblt. Daniel, you mentioned that > almost nobody supports hardware acceleration, but even without any > specific hardware support, surely even if bitblt() is implemented just > as a memcpy(), it has to be faster than redrawing all of the characters > doesn't it? Getting rid of the panning if it isn't generally supported > I can see, but I don't understand killing bitblt even if most devices > don't accelerate it. There are multiple ways to implement scrolling: 1. If the hardware supports a larger virtual screen and panning, and the virtual screen is enabled, most scrolling can be implemented by panning, with a casual copy when reaching the bottom (or top) of the virtual screen. This mode is (was) available on most graphics hardware with dedicated graphics memory. 2. If a 2D acceleration engine is available, copying (and clearing/filling) can be implemented by rectangle copy/fill operations. 3. Rectangle copy/fill by the CPU is always available. 4. Redrawing characters by the CPU is always available. Which option was used depended on the hardware: not all options are available everywhere, and some perform better than others. E.g. on PCI graphics cards, reading graphics memory by the CPU is usually very slow, so option 3 is much slower than option 4 (given a sufficiently fast CPU). AFAIU, option 2 is not suitable for modern systems with 3D acceleration. On the older (slower) systems (lacking VGA text mode) for which fbcon was originally written, option 4 is usually the slowest. Support for 1-3 were removed in commit 39aead8373b3c20b ("fbcon: Disable accelerated scrolling"), which claimed only 3 (DRM) drivers made use of this, ignoring the other 32 (fbdev) drivers making use of it. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: fbcon: remove soft scrollback code (missing Doc. patch) 2021-01-22 18:55 ` Phillip Susi 2021-01-25 15:39 ` Geert Uytterhoeven @ 2021-02-02 14:18 ` Daniel Vetter 2021-02-02 15:13 ` Phillip Susi 1 sibling, 1 reply; 23+ messages in thread From: Daniel Vetter @ 2021-02-02 14:18 UTC (permalink / raw) To: Phillip Susi Cc: Geert Uytterhoeven, Daniel Vetter, Linus Torvalds, Pavel Machek, Randy Dunlap, LKML, linux-doc, Greg Kroah-Hartman, dri-devel, Linux Fbdev development list On Fri, Jan 22, 2021 at 01:55:04PM -0500, Phillip Susi wrote: > > Geert Uytterhoeven writes: > > Judging from some of the comments in the code, it looks like you were > one of the original authors of fbcon? I haven't been able to find any > of these sczbot crash reports, and am not sure how fuzzing syscalls > would really affect this code ( it's not really handling a buch of > ioctls or otherwise taking arguments from user space ) , but I am a bit > confused as to why the softback was implemented the way that it was. > > vgacon simply copies the main buffer to vram in ->set_origin() and then > changes the pointers to operate out of the much larger vram while that > virtual terminal is active. If I understand it correctly, it looks like > fbcon instead opts to operate out of the main buffer but rescue lines as > they are scrolled off and relocate them to the softback buffer. This > seems to be rather more convoluted. > > I'm thinking of re-implementing scrollback more like the way vgacon does > it: allocate a big "vram" buffer and operate out of that. Obviously > ->scroll() and ->scrolldelta() have to actually repaint the screen rather > than simply change the pointer register, but that should be about the > only difference. > > I have also noticed that there was some code to use hardware panning of > the video buffer rather than having to do a block bitblt to scroll the > contents of the screen, but that it was disabled because virtually no > video drivers actually implemented it? That seems like a shame, but if > it is so, then there's no sense carrying the dead code so I think I'll > clean that up now. > > Now that I look at it again, everything is simply always redrawn now > instead of even doing a simple bitblt. Daniel, you mentioned that > almost nobody supports hardware acceleration, but even without any > specific hardware support, surely even if bitblt() is implemented just > as a memcpy(), it has to be faster than redrawing all of the characters > doesn't it? Getting rid of the panning if it isn't generally supported > I can see, but I don't understand killing bitblt even if most devices > don't accelerate it. Just a quick comment on this: Since most framebuffers are write-combining, and reads from that tend to be ~3 orders of magnitude slower than writes (at least on the pile of machines I looked at here, there's big differences, and some special streaming cpu instructions to make the reading side not so slow). So scrolling by copying tends to be significantly slower than just redrawing everything. And once you're at that point it's really hard to write a 2d acceleration which is consistently faster than just cpu rendering. If you're interested in why 2d acceleration is rather hard as a general problem, not just specific to fbcon, I wrote a blog on that a while ago: https://blog.ffwll.ch/2018/08/no-2d-in-drm.html Cheers, Daniel > In addition, I noticed that ->screen_pos() was changed to just return > vc_origin+offset. fbcon is the only console driver to implement > ->screenpos() and if not implemented, vt defaults to using > vc_visible_origin+offset, so it looks like this function isn't needed at > all anymore and ->screen_pos() can be removed from struct consw. > > Does this make sense or am I talking crazy? -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: fbcon: remove soft scrollback code (missing Doc. patch) 2021-02-02 14:18 ` Daniel Vetter @ 2021-02-02 15:13 ` Phillip Susi 2021-02-02 15:23 ` Daniel Vetter 0 siblings, 1 reply; 23+ messages in thread From: Phillip Susi @ 2021-02-02 15:13 UTC (permalink / raw) To: Daniel Vetter Cc: Geert Uytterhoeven, Linus Torvalds, Pavel Machek, Randy Dunlap, LKML, linux-doc, Greg Kroah-Hartman, dri-devel, Linux Fbdev development list Daniel Vetter writes: > Just a quick comment on this: Since most framebuffers are write-combining, > and reads from that tend to be ~3 orders of magnitude slower than writes > (at least on the pile of machines I looked at here, there's big > differences, and some special streaming cpu instructions to make the > reading side not so slow). > > So scrolling by copying tends to be significantly slower than just > redrawing everything. I know this was the case years ago with AGP as iirc, it doubled ( 4x, 8x ) the PCI clock rate but only for writes wasn't it? I thought this was no longer an issue with PCIe, but if it is, then I guess I'll go ahead with cleaning up the dead code and having it re-render with the larger text buffer. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: fbcon: remove soft scrollback code (missing Doc. patch) 2021-02-02 15:13 ` Phillip Susi @ 2021-02-02 15:23 ` Daniel Vetter 0 siblings, 0 replies; 23+ messages in thread From: Daniel Vetter @ 2021-02-02 15:23 UTC (permalink / raw) To: Phillip Susi Cc: Daniel Vetter, Geert Uytterhoeven, Linus Torvalds, Pavel Machek, Randy Dunlap, LKML, linux-doc, Greg Kroah-Hartman, dri-devel, Linux Fbdev development list On Tue, Feb 02, 2021 at 10:13:14AM -0500, Phillip Susi wrote: > > Daniel Vetter writes: > > > Just a quick comment on this: Since most framebuffers are write-combining, > > and reads from that tend to be ~3 orders of magnitude slower than writes > > (at least on the pile of machines I looked at here, there's big > > differences, and some special streaming cpu instructions to make the > > reading side not so slow). > > > > So scrolling by copying tends to be significantly slower than just > > redrawing everything. > > I know this was the case years ago with AGP as iirc, it doubled ( 4x, 8x > ) the PCI clock rate but only for writes wasn't it? I thought this was > no longer an issue with PCIe, but if it is, then I guess I'll go ahead > with cleaning up the dead code and having it re-render with the larger > text buffer. Still the same with PCIe, probably gotten worse since uncached reads are still as slow, but write-combined writes have gotten much faster even. There's work going on to have a coherent link to gpus which would allow fully cached reads and writes, early with nvlink and now as a standard with CXL (https://en.wikipedia.org/wiki/Compute_Express_Link) But that's aimed at big compute jobs for servers, not really for display. Also some on-die gpus have become fully coherent, but again only for render/compute buffers, not for the display framebuffer. So all together 0 signs this is changing going forward, reading from framebuffers is slow. Ok there's some exceptions: For manual update buffers (defio for fbdev drivers, drm also supports this with an entire set of helpers) the framebuffer used by the cpu is sometimes (but very often still not) cached. Imo not worth optimizing for, since for the drivers where it is cached they either have no blitter, or it's really tiny panels behind spi links and similar, so not going to be fast anyway. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: fbcon: remove soft scrollback code 2021-01-08 23:11 ` Linus Torvalds 2021-01-12 15:00 ` Phillip Susi 2021-01-12 15:57 ` Daniel Vetter @ 2021-01-14 17:43 ` Alan Mackenzie 2 siblings, 0 replies; 23+ messages in thread From: Alan Mackenzie @ 2021-01-14 17:43 UTC (permalink / raw) To: linux-kernel Hello, lkml. This is my first post to the list. From: Linus Torvalds <> Date: Fri, 8 Jan 2021 15:11:34 -0800 Subject:Re: fbcon: remove soft scrollback code (missing Doc. patch) >On Fri, Jan 8, 2021 at 11:13 AM Phillip Susi ><phill@thesusis.net> wrote: >> > Could we pause this madness? Scrollback is still useful. I needed it >> > today... it was too small, so command results I was looking for >> > already scrolled away, but... life will be really painful with 0 >> > scrollback. >> > You'll need it, too... as soon as you get oops and will want to see >> > errors just prior to that oops. >> > If it means I get to maintain it... I'm not happy about it but that's >> > better than no scrollback. >> Amen! What self respecting admin installs a gui on servers? What do >> we have to do to get this back in? What was so buggy with this code >> that it needed to be removed? Why was it such a burden to just leave >> it be? I am an Emacs maintainer, and do all my text work on the Linux console. My distribution is Gentoo. Whilst it may be an exaggeration to say Linux will become unusable to me without this scrolling facility, it's not much of one. For the moment, I can get by by not upgrading my kernel, but that's not a long term solution. >It really was buggy, with security implications. And we have no >maintainers. The first I heard of these problems was yesterday, when somebody posted a heads-up in the Gentoo users' list. I'm disappointed not to have heard of this around the time the decision was taken. Perhaps the problems, and request for a maintainer, could have been more widely circulated. I would have offered to stand up then, just as I am offering to stand up now. I have as yet no experience in kernel hacking, though I did look closely at the console code a few years back, with a view to enhancing it to handle more than 256 glyphs and 16 colours. It struck me as code badly needing some love. >So the scroll-back code can't come back until we have a maintainer and a >cleaner and simpler implementation. I offer my services, just as others have done. >And no, maintaining it really doesn't mean "just get it back to the old >broken state". Is there a coherent description of the problems (including the security problems) anywhere? >So far I haven't actually seen any patches, which means that it's not >coming back. But with a few pertinent patches, it might come back, perhaps? [ .... ] Linus -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2021-02-03 8:04 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <git-mailbomb-linux-master-50145474f6ef4a9c19205b173da6264a644c7489@kernel.org> 2020-09-15 1:18 ` fbcon: remove soft scrollback code (missing Doc. patch) Randy Dunlap 2020-09-15 1:28 ` Bhaskar Chowdhury 2020-09-15 1:30 ` Linus Torvalds 2020-09-15 1:34 ` Randy Dunlap 2020-09-15 1:28 ` Linus Torvalds 2020-09-16 20:54 ` Pavel Machek 2020-09-18 10:27 ` Adam Borowski 2020-09-30 21:29 ` Maciej W. Rozycki 2021-01-08 19:01 ` Phillip Susi 2021-01-08 23:11 ` Linus Torvalds 2021-01-12 15:00 ` Phillip Susi 2021-01-12 16:11 ` Greg Kroah-Hartman 2021-01-12 15:57 ` Daniel Vetter 2021-01-14 15:56 ` Geert Uytterhoeven 2021-01-14 16:11 ` Daniel Vetter 2021-01-15 8:06 ` Geert Uytterhoeven 2021-02-03 8:03 ` Thomas Zimmermann 2021-01-22 18:55 ` Phillip Susi 2021-01-25 15:39 ` Geert Uytterhoeven 2021-02-02 14:18 ` Daniel Vetter 2021-02-02 15:13 ` Phillip Susi 2021-02-02 15:23 ` Daniel Vetter 2021-01-14 17:43 ` fbcon: remove soft scrollback code Alan Mackenzie
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).