From: Helge Deller <deller@gmx.de> To: Gerd Hoffmann <kraxel@redhat.com> Cc: Thomas Zimmermann <tzimmermann@suse.de>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, linux-fbdev@vger.kernel.org, Sven Schnelle <svens@stackframe.org>, Linus Torvalds <torvalds@linux-foundation.org>, Javier Martinez Canillas <javierm@redhat.com>, Daniel Vetter <daniel.vetter@intel.com>, Ilia Mirkin <imirkin@alum.mit.edu>, Tomi Valkeinen <tomi.valkeinen@ti.com>, dri-devel@lists.freedesktop.org, Jani Nikula <jani.nikula@linux.intel.com>, Pavel Machek <pavel@ucw.cz>, linux-kernel@vger.kernel.org, Geert Uytterhoeven <geert@linux-m68k.org>, Sam Ravnborg <sam@ravnborg.org>, Claudio Suarez <cssk@net-c.es> Subject: Re: [PATCH 2/2] Revert "fbcon: Disable accelerated scrolling" Date: Mon, 24 Jan 2022 12:10:19 +0100 [thread overview] Message-ID: <64fd46cb-9746-3fd0-ec92-c64dba76875a@gmx.de> (raw) In-Reply-To: <20220121072006.ylw2hdl7jbkbwnre@sirius.home.kraxel.org> On 1/21/22 08:20, Gerd Hoffmann wrote: >>> So if this really has to come back then I think the pragmatic approach is >>> to do it behind a CONFIG_FBCON_ACCEL, default n, and with a huge warning >>> that enabling that shouldn't be done for any distro which only enables >>> firmware and drm fbdev drivers. >> >> Thanks for coming back on this, but quite frankly I don't understand >> that request. How should that warning look like, something along: >> "BE WARNED: The framebuffer text console on your non-DRM supported >> graphic card will then run faster and smoother if you enable this option." >> That doesn't make sense. People and distros would want to enable that. > > Nope. Most distros want disable fbdev drivers rather sooner than later. > The fbdev drivers enabled in the fedora kernel today: > > CONFIG_FB_VGA16=m > CONFIG_FB_VESA=y > CONFIG_FB_EFI=y > CONFIG_FB_SSD1307=m > > CONFIG_FB_VESA + CONFIG_FB_EFI will go away soon, with simpledrm taking > over their role. That's Ok. Nevertheless, some distros and platforms will still need fbdev drivers for various reasons. >> And if a distro *just* has firmware and drm fbdev drivers enabled, >> none of the non-DRM graphic cards would be loaded anyway and this code >> wouldn't be executed anyway. > > Yes, exactly. That's why there is no point in compiling that code. As long as you have a graphic card which is not supported by DRM you still need it. Here is my proposed way forward: a) I will resend the patches which reverts the remove-fbcon-hardware-scolling patches to the mailing lists. I'll adjust the stable tags and update the commit messages. b) Then after some days I'll include it in the fbdev for-next git branch. That way it's included in the various build & test chains. c) If everything is working well, I'll push that change during the next merge window for kernel 5.18. If problems arise we will need to discuss. While the patches are in the fbdev git tree we should decide how to exclude code which is not needed for DRM. What about this proposal: a) adding a Kconfig option like: CONFIG_FB_DRIVERS - enable if you need the fbdev drivers. For DRM-only this should be disabled. b) Add to every native fbdev driver a "depends on FB_DRIVERS" in the Kconfig files. c) That way we can use "#if defined(CONFIG_FB_DRIVERS).." to exclude code in fbcon which isn't needed by DRM. Thoughts? Helge
WARNING: multiple messages have this Message-ID (diff)
From: Helge Deller <deller@gmx.de> To: Gerd Hoffmann <kraxel@redhat.com> Cc: linux-fbdev@vger.kernel.org, Pavel Machek <pavel@ucw.cz>, Sam Ravnborg <sam@ravnborg.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sven Schnelle <svens@stackframe.org>, Javier Martinez Canillas <javierm@redhat.com>, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Claudio Suarez <cssk@net-c.es>, Tomi Valkeinen <tomi.valkeinen@ti.com>, Geert Uytterhoeven <geert@linux-m68k.org>, Thomas Zimmermann <tzimmermann@suse.de>, Daniel Vetter <daniel.vetter@intel.com>, Linus Torvalds <torvalds@linux-foundation.org> Subject: Re: [PATCH 2/2] Revert "fbcon: Disable accelerated scrolling" Date: Mon, 24 Jan 2022 12:10:19 +0100 [thread overview] Message-ID: <64fd46cb-9746-3fd0-ec92-c64dba76875a@gmx.de> (raw) In-Reply-To: <20220121072006.ylw2hdl7jbkbwnre@sirius.home.kraxel.org> On 1/21/22 08:20, Gerd Hoffmann wrote: >>> So if this really has to come back then I think the pragmatic approach is >>> to do it behind a CONFIG_FBCON_ACCEL, default n, and with a huge warning >>> that enabling that shouldn't be done for any distro which only enables >>> firmware and drm fbdev drivers. >> >> Thanks for coming back on this, but quite frankly I don't understand >> that request. How should that warning look like, something along: >> "BE WARNED: The framebuffer text console on your non-DRM supported >> graphic card will then run faster and smoother if you enable this option." >> That doesn't make sense. People and distros would want to enable that. > > Nope. Most distros want disable fbdev drivers rather sooner than later. > The fbdev drivers enabled in the fedora kernel today: > > CONFIG_FB_VGA16=m > CONFIG_FB_VESA=y > CONFIG_FB_EFI=y > CONFIG_FB_SSD1307=m > > CONFIG_FB_VESA + CONFIG_FB_EFI will go away soon, with simpledrm taking > over their role. That's Ok. Nevertheless, some distros and platforms will still need fbdev drivers for various reasons. >> And if a distro *just* has firmware and drm fbdev drivers enabled, >> none of the non-DRM graphic cards would be loaded anyway and this code >> wouldn't be executed anyway. > > Yes, exactly. That's why there is no point in compiling that code. As long as you have a graphic card which is not supported by DRM you still need it. Here is my proposed way forward: a) I will resend the patches which reverts the remove-fbcon-hardware-scolling patches to the mailing lists. I'll adjust the stable tags and update the commit messages. b) Then after some days I'll include it in the fbdev for-next git branch. That way it's included in the various build & test chains. c) If everything is working well, I'll push that change during the next merge window for kernel 5.18. If problems arise we will need to discuss. While the patches are in the fbdev git tree we should decide how to exclude code which is not needed for DRM. What about this proposal: a) adding a Kconfig option like: CONFIG_FB_DRIVERS - enable if you need the fbdev drivers. For DRM-only this should be disabled. b) Add to every native fbdev driver a "depends on FB_DRIVERS" in the Kconfig files. c) That way we can use "#if defined(CONFIG_FB_DRIVERS).." to exclude code in fbcon which isn't needed by DRM. Thoughts? Helge
next prev parent reply other threads:[~2022-01-24 11:11 UTC|newest] Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-19 11:08 [PATCH 0/2] Fix regression introduced by disabling accelerated scrolling in fbcon Helge Deller 2022-01-19 11:08 ` [PATCH 1/2] Revert "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)" Helge Deller 2022-01-19 11:08 ` [PATCH 2/2] Revert "fbcon: Disable accelerated scrolling" Helge Deller 2022-01-19 11:22 ` Greg Kroah-Hartman 2022-01-19 11:22 ` Greg Kroah-Hartman 2022-01-19 11:28 ` Greg Kroah-Hartman 2022-01-19 11:28 ` Greg Kroah-Hartman 2022-01-19 11:47 ` Geert Uytterhoeven 2022-01-19 11:47 ` Geert Uytterhoeven 2022-01-19 12:28 ` Helge Deller 2022-01-19 12:28 ` Helge Deller 2022-01-19 14:01 ` Linus Torvalds 2022-01-19 14:01 ` Linus Torvalds 2022-01-19 14:11 ` Helge Deller 2022-01-19 14:11 ` Helge Deller 2022-01-19 14:34 ` Daniel Vetter 2022-01-19 14:34 ` Daniel Vetter 2022-01-19 15:05 ` Sven Schnelle 2022-01-19 15:05 ` Sven Schnelle 2022-01-19 15:37 ` Thomas Zimmermann 2022-01-19 15:37 ` Thomas Zimmermann 2022-01-19 16:55 ` Helge Deller 2022-01-19 16:55 ` Helge Deller 2022-01-19 15:42 ` Daniel Vetter 2022-01-19 15:42 ` Daniel Vetter 2022-01-19 15:54 ` Helge Deller 2022-01-19 15:54 ` Helge Deller 2022-01-19 16:13 ` Jani Nikula 2022-01-19 16:13 ` Jani Nikula 2022-01-19 16:31 ` Daniel Vetter 2022-01-19 16:31 ` Daniel Vetter 2022-01-19 15:18 ` Helge Deller 2022-01-19 15:18 ` Helge Deller 2022-01-19 13:01 ` Sven Schnelle 2022-01-19 13:01 ` Sven Schnelle 2022-01-19 13:35 ` Greg Kroah-Hartman 2022-01-19 13:35 ` Greg Kroah-Hartman 2022-01-20 14:30 ` Daniel Vetter 2022-01-20 14:30 ` Daniel Vetter 2022-01-20 17:01 ` Helge Deller 2022-01-21 7:20 ` Gerd Hoffmann 2022-01-21 7:20 ` Gerd Hoffmann 2022-01-24 11:10 ` Helge Deller [this message] 2022-01-24 11:10 ` Helge Deller 2022-01-24 11:28 ` Javier Martinez Canillas 2022-01-24 11:28 ` Javier Martinez Canillas 2022-01-24 11:33 ` Thomas Zimmermann 2022-01-24 11:33 ` Thomas Zimmermann 2022-01-24 11:50 ` Javier Martinez Canillas 2022-01-24 11:50 ` Javier Martinez Canillas 2022-01-24 15:29 ` Helge Deller 2022-01-24 15:29 ` Helge Deller 2022-01-24 15:45 ` Thomas Zimmermann 2022-01-24 15:45 ` Thomas Zimmermann 2022-01-24 15:50 ` Geert Uytterhoeven 2022-01-24 15:50 ` Geert Uytterhoeven 2022-01-24 15:58 ` Daniel Vetter 2022-01-24 15:58 ` Daniel Vetter 2022-01-24 15:50 ` Geert Uytterhoeven 2022-01-24 15:50 ` Geert Uytterhoeven 2022-01-24 16:11 ` Thomas Zimmermann 2022-01-24 16:11 ` Thomas Zimmermann 2022-01-19 12:45 ` [PATCH 0/2] Fix regression introduced by disabling accelerated scrolling in fbcon Geert Uytterhoeven 2022-01-19 12:45 ` Geert Uytterhoeven 2022-01-19 13:02 ` Sven Schnelle 2022-01-19 13:02 ` Sven Schnelle
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=64fd46cb-9746-3fd0-ec92-c64dba76875a@gmx.de \ --to=deller@gmx.de \ --cc=cssk@net-c.es \ --cc=daniel.vetter@intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=geert@linux-m68k.org \ --cc=gregkh@linuxfoundation.org \ --cc=imirkin@alum.mit.edu \ --cc=jani.nikula@linux.intel.com \ --cc=javierm@redhat.com \ --cc=kraxel@redhat.com \ --cc=linux-fbdev@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=pavel@ucw.cz \ --cc=sam@ravnborg.org \ --cc=svens@stackframe.org \ --cc=tomi.valkeinen@ti.com \ --cc=torvalds@linux-foundation.org \ --cc=tzimmermann@suse.de \ /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: linkBe 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.