Re: [PATCH v2 1/2] fbdev: Split frame buffer support in FB and FB_CORE symbols
flat view
From: "Arnd Bergmann" <arnd@arndb.de>
Date: 2023-07-01 22:25:18
Also in:
dri-devel, lkml
On Sat, Jul 1, 2023, at 23:44, Javier Martinez Canillas wrote:
Currently the CONFIG_FB option has to be enabled even if no legacy fbdev drivers are needed (e.g: only to have support for framebuffer consoles). The DRM subsystem has a fbdev emulation layer, but depends on CONFIG_FB and so it can only be enabled if that dependency is enabled as well. That means fbdev drivers have to be explicitly disabled if users want to enable CONFIG_FB, only to use fbcon and/or the DRM fbdev emulation layer. This patch introduces a non-visible CONFIG_FB_CORE symbol that could be enabled just to have core support needed for CONFIG_DRM_FBDEV_EMULATION, allowing CONFIG_FB to be disabled (and automatically disabling all the fbdev drivers). Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> ---
I found two more things now:
quoted hunk ↗ jump to hunk
+menuconfig FB_CORE + tristate "Core support for frame buffer devices" +
This is not actually a hidden option, since you left the prompt
after the 'tristate' keyword. There is also no pointn in having
it as a menu, just use the simpler
config FB_CORE
tristate
or (as in my other email)
config FB_CORE
def_tristate FB || (DRM && DRM_FBDEV_EMULATION)
quoted hunk ↗ jump to hunk
@@ -44,7 +54,7 @@ menuconfig FB config FIRMWARE_EDID bool "Enable firmware EDID" - depends on FB + depends on FB_CORE help This enables access to the EDID transferred from the firmware. On the i386, this is from the Video BIOS. Enable this if DDC/I2C@@ -59,7 +69,7 @@ config FIRMWARE_EDID config FB_DEVICE bool "Provide legacy /dev/fb* device" - depends on FB + select FB_CORE default y help Say Y here if you want the legacy /dev/fb* device file and
These are now the only user visible sub-options when CONFIG_FB is
disabled. I missed FIRMWARE_EDID earlier, but this also looks like
it can clearly be left as depending on FB since nothing else calls
fb_firmware_edid. In fact, it looks like all of fbmon.c could be
left out since none of its exported symbols are needed for DRM.
That would leave CONFIG_FB_DEVICE as the only user visible option
for DRM-only configs, which is slightly odd for the menuconfig,
so I still wonder if that could be done differently.
Is there actually a point in configurations for kernels with FB=y,
DRM=n and FB_DEVICE=n? If we don't expect that to be a useful
configuration, an easier way would be to have CONFIG_FB turn it
on implicitly and instead have a user-visible Kconfig option
below CONFIG_DRM_FBDEV_EMULATION that allows controlling the
creation of /dev/fb*.
Arnd