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 <[email protected]>
> AuthorDate: Mon Sep 7 11:45:27 2020 -0700
> Committer: Linus Torvalds <[email protected]>
> 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 <[email protected]>
> AuthorDate: Wed Sep 9 14:53:50 2020 -0700
> Committer: Linus Torvalds <[email protected]>
> 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
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 <[email protected]>
>> AuthorDate: Mon Sep 7 11:45:27 2020 -0700
>> Committer: Linus Torvalds <[email protected]>
>> 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 <[email protected]>
>> AuthorDate: Wed Sep 9 14:53:50 2020 -0700
>> Committer: Linus Torvalds <[email protected]>
>> 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
>
On Mon, Sep 14, 2020 at 6:19 PM Randy Dunlap <[email protected]> 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
On Mon, Sep 14, 2020 at 6:28 PM Bhaskar Chowdhury <[email protected]> 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
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 <[email protected]>
>>> AuthorDate: Mon Sep 7 11:45:27 2020 -0700
>>> Committer:? Linus Torvalds <[email protected]>
>>> 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 <[email protected]>
>>> AuthorDate: Wed Sep 9 14:53:50 2020 -0700
>>> Committer:? Linus Torvalds <[email protected]>
>>> 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
On Mon 2020-09-14 18:28:34, Linus Torvalds wrote:
> On Mon, Sep 14, 2020 at 6:19 PM Randy Dunlap <[email protected]> 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
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
⠈⠳⣄⠀⠀⠀⠀
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
> 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.
On Fri, Jan 8, 2021 at 11:13 AM Phillip Susi <[email protected]> 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
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?
On Sat, Jan 9, 2021 at 12:11 AM Linus Torvalds
<[email protected]> wrote:
>
> On Fri, Jan 8, 2021 at 11:13 AM Phillip Susi <[email protected]> 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
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
Hi Daniel,
CC linux-fbdev
On Tue, Jan 12, 2021 at 5:00 PM Daniel Vetter <[email protected]> wrote:
> On Sat, Jan 9, 2021 at 12:11 AM Linus Torvalds
> <[email protected]> wrote:
> > On Fri, Jan 8, 2021 at 11:13 AM Phillip Susi <[email protected]> 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 -- [email protected]
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
On Thu, Jan 14, 2021 at 4:56 PM Geert Uytterhoeven <[email protected]> wrote:
>
> Hi Daniel,
>
> CC linux-fbdev
>
> On Tue, Jan 12, 2021 at 5:00 PM Daniel Vetter <[email protected]> wrote:
> > On Sat, Jan 9, 2021 at 12:11 AM Linus Torvalds
> > <[email protected]> wrote:
> > > On Fri, Jan 8, 2021 at 11:13 AM Phillip Susi <[email protected]> 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 -- [email protected]
>
> 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
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
><[email protected]> 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).
Hi Daniel,
On Thu, Jan 14, 2021 at 5:11 PM Daniel Vetter <[email protected]> wrote:
> On Thu, Jan 14, 2021 at 4:56 PM Geert Uytterhoeven <[email protected]> wrote:
> > On Tue, Jan 12, 2021 at 5:00 PM Daniel Vetter <[email protected]> wrote:
> > > On Sat, Jan 9, 2021 at 12:11 AM Linus Torvalds
> > > <[email protected]> wrote:
> > > > On Fri, Jan 8, 2021 at 11:13 AM Phillip Susi <[email protected]> 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 -- [email protected]
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
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?
Hi Phillip,
On Fri, Jan 22, 2021 at 8:26 PM Phillip Susi <[email protected]> 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 -- [email protected]
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
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
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.
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
Hi
Am 15.01.21 um 09:06 schrieb Geert Uytterhoeven:
> Hi Daniel,
>
> On Thu, Jan 14, 2021 at 5:11 PM Daniel Vetter <[email protected]> wrote:
>> On Thu, Jan 14, 2021 at 4:56 PM Geert Uytterhoeven <[email protected]> wrote:
>>> On Tue, Jan 12, 2021 at 5:00 PM Daniel Vetter <[email protected]> wrote:
>>>> On Sat, Jan 9, 2021 at 12:11 AM Linus Torvalds
>>>> <[email protected]> wrote:
>>>>> On Fri, Jan 8, 2021 at 11:13 AM Phillip Susi <[email protected]> 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