From: Sam Ravnborg <sam-uyr5N9Q2VtJg9hUCZPvPmw@public.gmane.org>
To: Daniel Vetter <daniel.vetter-/w4YWyX8dFk@public.gmane.org>
Cc: Bartlomiej Zolnierkiewicz
<b.zolnierkie-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
Tetsuo Handa
<penguin-kernel-1yMVhJb1mP/7nzcFbJAaVXf5DAMn2ifp@public.gmane.org>,
Greg Kroah-Hartman
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
"Gustavo A. R. Silva"
<gustavoars-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
DRI Development
<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
Peilin Ye <yepeilin.cs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
George Kennedy
<george.kennedy-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,
Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>,
Ben Skeggs <bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Daniel Vetter
<daniel.vetter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Nathan Chancellor
<natechancellor-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Jiri Slaby <jirislaby-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
Subject: Re: [PATCH] fbcon: Disable accelerated scrolling
Date: Wed, 28 Oct 2020 19:50:29 +0100 [thread overview]
Message-ID: <20201028185029.GA683411@ravnborg.org> (raw)
In-Reply-To: <20201028160600.3752105-1-daniel.vetter-/w4YWyX8dFk@public.gmane.org>
Hi Daniel.
On Wed, Oct 28, 2020 at 05:06:00PM +0100, Daniel Vetter wrote:
> So ever since syzbot discovered fbcon, we have solid proof that it's
> full of bugs. And often the solution is to just delete code and remove
> features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
>
> Now the problem is that most modern-ish drivers really only treat
> fbcon as an dumb kernel console until userspace takes over, and Oops
> printer for some emergencies. Looking at drm drivers and the basic
> vesa/efi fbdev drivers shows that only 3 drivers support any kind of
> acceleration:
>
> - nouveau, seems to be enabled by default
> - omapdrm, when a DMM remapper exists using remapper rewriting for
> y/xpanning
> - gma500, but that is getting deleted now for the GTT remapper trick,
> and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA
> flag, so unused (and could be deleted already I think).
>
> No other driver supportes accelerated fbcon. And fbcon is the only
> user of this accel code (it's not exposed as uapi through ioctls),
> which means we could garbage collect fairly enormous amounts of code
> if we kill this.
>
> Plus because syzbot only runs on virtual hardware, and none of the
> drivers for that have acceleration, we'd remove a huge gap in testing.
> And there's no other even remotely comprehensive testing aside from
> syzbot.
>
> This patch here just disables the acceleration code by always
> redrawing when scrolling. The plan is that once this has been merged
> for well over a year in released kernels, we can start to go around
> and delete a lot of code.
See below for a warning fix.
Some figures from trying to toss accel code out from a few fbdev drivers:
drivers/video/fbdev/cirrusfb.c | 300 +----------------------------------------
1 file changed, 4 insertions(+), 296 deletions(-)
drivers/video/fbdev/aty/radeon_accel.c | 174 ---------------------------------
drivers/video/fbdev/aty/radeon_base.c | 43 ++------
drivers/video/fbdev/aty/radeon_pm.c | 7 --
drivers/video/fbdev/aty/radeonfb.h | 3 -
4 files changed, 7 insertions(+), 220 deletions(-)
This may open up the discussion if the right course of action would be
to drop the drivers in favour of drm counterparts - but thats another
story.
Sam
> @@ -1961,7 +1963,6 @@ static void updatescrollmode(struct fbcon_display *p,
> {
> struct fbcon_ops *ops = info->fbcon_par;
> int fh = vc->vc_font.height;
> - int cap = info->flags;
> u16 t = 0;
> int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
> info->fix.xpanstep);
> @@ -1969,37 +1970,12 @@ static void updatescrollmode(struct fbcon_display *p,
> int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
> int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
> info->var.xres_virtual);
> - int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
> - divides(ypan, vc->vc_font.height) && vyres > yres;
> - int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
> - divides(ywrap, vc->vc_font.height) &&
> - divides(vc->vc_font.height, vyres) &&
> - divides(vc->vc_font.height, yres);
> - int reading_fast = cap & FBINFO_READS_FAST;
> - int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
> - !(cap & FBINFO_HWACCEL_DISABLED);
> - int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
> - !(cap & FBINFO_HWACCEL_DISABLED);
Some bot will likely tell you that this causes warnings.
At least it did in my sparc64 build.
Fix:
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 398914e035e9..e8b009c621d8 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2150,10 +2150,6 @@ static void updatescrollmode(struct fbcon_display *p,
{
struct fbcon_ops *ops = info->fbcon_par;
int fh = vc->vc_font.height;
- u16 t = 0;
- int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
- info->fix.xpanstep);
- int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
info->var.xres_virtual);
WARNING: multiple messages have this Message-ID (diff)
From: Sam Ravnborg <sam@ravnborg.org>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
"Gustavo A. R. Silva" <gustavoars@kernel.org>,
DRI Development <dri-devel@lists.freedesktop.org>,
Peilin Ye <yepeilin.cs@gmail.com>,
George Kennedy <george.kennedy@oracle.com>,
Tomi Valkeinen <tomi.valkeinen@ti.com>,
Ben Skeggs <bskeggs@redhat.com>,
nouveau@lists.freedesktop.org,
Daniel Vetter <daniel.vetter@intel.com>,
Nathan Chancellor <natechancellor@gmail.com>,
Jiri Slaby <jirislaby@kernel.org>, Peter Rosin <peda@axentia.se>
Subject: Re: [PATCH] fbcon: Disable accelerated scrolling
Date: Wed, 28 Oct 2020 19:50:29 +0100 [thread overview]
Message-ID: <20201028185029.GA683411@ravnborg.org> (raw)
In-Reply-To: <20201028160600.3752105-1-daniel.vetter@ffwll.ch>
Hi Daniel.
On Wed, Oct 28, 2020 at 05:06:00PM +0100, Daniel Vetter wrote:
> So ever since syzbot discovered fbcon, we have solid proof that it's
> full of bugs. And often the solution is to just delete code and remove
> features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
>
> Now the problem is that most modern-ish drivers really only treat
> fbcon as an dumb kernel console until userspace takes over, and Oops
> printer for some emergencies. Looking at drm drivers and the basic
> vesa/efi fbdev drivers shows that only 3 drivers support any kind of
> acceleration:
>
> - nouveau, seems to be enabled by default
> - omapdrm, when a DMM remapper exists using remapper rewriting for
> y/xpanning
> - gma500, but that is getting deleted now for the GTT remapper trick,
> and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA
> flag, so unused (and could be deleted already I think).
>
> No other driver supportes accelerated fbcon. And fbcon is the only
> user of this accel code (it's not exposed as uapi through ioctls),
> which means we could garbage collect fairly enormous amounts of code
> if we kill this.
>
> Plus because syzbot only runs on virtual hardware, and none of the
> drivers for that have acceleration, we'd remove a huge gap in testing.
> And there's no other even remotely comprehensive testing aside from
> syzbot.
>
> This patch here just disables the acceleration code by always
> redrawing when scrolling. The plan is that once this has been merged
> for well over a year in released kernels, we can start to go around
> and delete a lot of code.
See below for a warning fix.
Some figures from trying to toss accel code out from a few fbdev drivers:
drivers/video/fbdev/cirrusfb.c | 300 +----------------------------------------
1 file changed, 4 insertions(+), 296 deletions(-)
drivers/video/fbdev/aty/radeon_accel.c | 174 ---------------------------------
drivers/video/fbdev/aty/radeon_base.c | 43 ++------
drivers/video/fbdev/aty/radeon_pm.c | 7 --
drivers/video/fbdev/aty/radeonfb.h | 3 -
4 files changed, 7 insertions(+), 220 deletions(-)
This may open up the discussion if the right course of action would be
to drop the drivers in favour of drm counterparts - but thats another
story.
Sam
> @@ -1961,7 +1963,6 @@ static void updatescrollmode(struct fbcon_display *p,
> {
> struct fbcon_ops *ops = info->fbcon_par;
> int fh = vc->vc_font.height;
> - int cap = info->flags;
> u16 t = 0;
> int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
> info->fix.xpanstep);
> @@ -1969,37 +1970,12 @@ static void updatescrollmode(struct fbcon_display *p,
> int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
> int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
> info->var.xres_virtual);
> - int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
> - divides(ypan, vc->vc_font.height) && vyres > yres;
> - int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
> - divides(ywrap, vc->vc_font.height) &&
> - divides(vc->vc_font.height, vyres) &&
> - divides(vc->vc_font.height, yres);
> - int reading_fast = cap & FBINFO_READS_FAST;
> - int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
> - !(cap & FBINFO_HWACCEL_DISABLED);
> - int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
> - !(cap & FBINFO_HWACCEL_DISABLED);
Some bot will likely tell you that this causes warnings.
At least it did in my sparc64 build.
Fix:
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 398914e035e9..e8b009c621d8 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2150,10 +2150,6 @@ static void updatescrollmode(struct fbcon_display *p,
{
struct fbcon_ops *ops = info->fbcon_par;
int fh = vc->vc_font.height;
- u16 t = 0;
- int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
- info->fix.xpanstep);
- int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
info->var.xres_virtual);
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-10-28 18:50 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-28 16:06 [PATCH] fbcon: Disable accelerated scrolling Daniel Vetter
2020-10-28 16:06 ` Daniel Vetter
[not found] ` <20201028160600.3752105-1-daniel.vetter-/w4YWyX8dFk@public.gmane.org>
2020-10-28 16:45 ` Sam Ravnborg
2020-10-28 16:45 ` Sam Ravnborg
[not found] ` <20201028164552.GA546379-uyr5N9Q2VtJg9hUCZPvPmw@public.gmane.org>
2020-10-28 16:48 ` Daniel Vetter
2020-10-28 16:48 ` Daniel Vetter
2020-10-28 16:57 ` Greg Kroah-Hartman
2020-10-28 16:57 ` Greg Kroah-Hartman
2020-10-28 18:50 ` Sam Ravnborg [this message]
2020-10-28 18:50 ` Sam Ravnborg
[not found] ` <20201028185029.GA683411-uyr5N9Q2VtJg9hUCZPvPmw@public.gmane.org>
2020-10-28 19:57 ` Daniel Vetter
2020-10-28 19:57 ` Daniel Vetter
2020-10-28 19:02 ` Thomas Zimmermann
2020-10-28 19:02 ` Thomas Zimmermann
[not found] ` <470585bd-74de-d652-928b-b03fe3bd8614-l3A5Bk7waGM@public.gmane.org>
2020-10-28 19:55 ` Daniel Vetter
2020-10-28 19:55 ` Daniel Vetter
[not found] ` <CAKMK7uEgn1ZMDpk=hnm7KODVBjUnNYiTsm-O-mDeuGRBi8qYxg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-10-29 8:07 ` Thomas Zimmermann
2020-10-29 8:07 ` Thomas Zimmermann
2020-10-29 5:42 ` Jiri Slaby
2020-10-29 5:42 ` Jiri Slaby
-- strict thread matches above, loose matches on Subject: below --
2020-10-29 10:14 [Intel-gfx] [PATCH 1/3] " Daniel Vetter
[not found] ` <20201029101428.4058311-1-daniel.vetter-/w4YWyX8dFk@public.gmane.org>
2020-10-29 13:22 ` [PATCH] " Daniel Vetter
2020-10-29 13:22 ` Daniel Vetter
[not found] ` <20201029132229.4068359-1-daniel.vetter-/w4YWyX8dFk@public.gmane.org>
2020-10-30 8:30 ` Tomi Valkeinen
2020-10-30 8:30 ` Tomi Valkeinen
2020-10-30 8:52 ` Daniel Vetter
2020-10-30 8:52 ` Daniel Vetter
2020-10-31 10:27 ` Geert Uytterhoeven
2020-10-31 10:27 ` Geert Uytterhoeven
2020-10-31 10:27 ` Geert Uytterhoeven
2020-10-31 14:17 ` Daniel Vetter
2020-10-31 14:17 ` Daniel Vetter
2020-10-31 14:17 ` Daniel Vetter
2020-11-18 9:21 ` Geert Uytterhoeven
2020-11-18 9:21 ` Geert Uytterhoeven
2020-11-18 9:21 ` Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201028185029.GA683411@ravnborg.org \
--to=sam-uyr5n9q2vtjg9huczpvpmw@public.gmane.org \
--cc=b.zolnierkie-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=daniel.vetter-/w4YWyX8dFk@public.gmane.org \
--cc=daniel.vetter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=george.kennedy-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
--cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
--cc=gustavoars-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=jirislaby-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=natechancellor-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org \
--cc=penguin-kernel-1yMVhJb1mP/7nzcFbJAaVXf5DAMn2ifp@public.gmane.org \
--cc=tomi.valkeinen-l0cyMroinI0@public.gmane.org \
--cc=torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=yepeilin.cs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.