archive mirror
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <>
To: Thomas Zimmermann <>,, "H . Peter Anvin" <>,
	Maarten Lankhorst <>,, Greg Kroah-Hartman <>,, Thomas Gleixner <>,
	Maxime Ripard <>,
	Borislav Petkov <>,
	Peter Robinson <>,
	Hans de Goede <>,, Ingo Molnar <>,
	David Airlie <>
Subject: Re: [RFC PATCH 0/4] Allow to use DRM fbdev emulation layer with CONFIG_FB disabled
Date: Sat, 28 Aug 2021 00:02:21 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <YSlI+ryYqoRxM7aB@phenom.ffwll.local>

Hello Daniel and Thomas,

On 8/27/21 10:20 PM, Daniel Vetter wrote:
> On Fri, Aug 27, 2021 at 07:50:23PM +0200, Thomas Zimmermann wrote:
>> Hi
>> Am 27.08.21 um 12:00 schrieb Javier Martinez Canillas:
>>> This patch series splits the fbdev core support in two different Kconfig
>>> symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to
>>> be disabled, while still using fbcon with the DRM fbdev emulation layer.
>> I'm skeptical. DRM's fbdev emulation is not just the console emulation, it's
>> a full fbdev device. You can see the related device file as /dev/fb*.
>> Providing the file while having CONFIG_FB disabled doesn't make much sense
>> to me. I know it's not pretty, but it's consistent at least.
>> If you want to remove fbdev, you could try to untangle fbdev and the console
>> emulation such that DRM can set up a console by itself. Old fbdev drives
>> would also set up the console individually.
> Yeah given the horrendous security track record of all that code, and the
> maze of handover we have (stuff like flicker free boot and all that) I'm
> wondering whether typing a new drmcon wouldn't be faster and a lot more
> maintainable.

We talked about a drmcon with Peter Robinson as well but then decided that a
way to disable CONFIG_FB but still having the DRM fbdev emulation could be a
intermediary step, hence these RFC patches.

But yes, I agree that a drmcon would be the proper approach for this, to not
need any fbdev support at all. We will just keep the explicit disable for the
fbdev drivers then in the meantime.

Thanks a lot for your feedback.

Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat

  reply	other threads:[~2021-08-27 22:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-27 10:00 [RFC PATCH 0/4] Allow to use DRM fbdev emulation layer with CONFIG_FB disabled Javier Martinez Canillas
2021-08-27 10:00 ` [RFC PATCH 1/4] fbdev: Rename fb_*_device() functions names to match what they do Javier Martinez Canillas
2021-08-27 17:50 ` [RFC PATCH 0/4] Allow to use DRM fbdev emulation layer with CONFIG_FB disabled Thomas Zimmermann
2021-08-27 20:20   ` Daniel Vetter
2021-08-27 22:02     ` Javier Martinez Canillas [this message]
2021-08-31 12:35       ` Daniel Vetter
2021-09-01  9:08         ` Javier Martinez Canillas
2021-09-02 14:31           ` Daniel Vetter
     [not found] <YS+Lhz9gg/>
2021-09-09 15:52 ` Noralf Trønnes
2021-09-09 16:27   ` Noralf Trønnes

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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 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).