Geert Uytterhoeven [off-list ref] writes:

Hello Geert and Thomas,

Hi Thomas,

On Wed, Jun 7, 2023 at 5:15 PM Thomas Zimmermann [off-list ref] wrote:

quoted

Am 07.06.23 um 10:48 schrieb Geert Uytterhoeven:

quoted

On Mon, Jun 5, 2023 at 4:48 PM Thomas Zimmermann [off-list ref] wrote:

quoted

--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig

@@ -57,6 +57,15 @@ config FIRMWARE_EDID
           combination with certain motherboards and monitors are known to
           suffer from this problem.

+config FB_DEVICE
+        bool "Provide legacy /dev/fb* device"

Perhaps "default y if !DRM", although that does not help for a
mixed drm/fbdev kernel build?

We could simply set it to "default y".  But OTOH is it worth making it a
default? Distributions will set it to the value they need/want. The very
few people that build their own kernels to get certain fbdev drivers
will certainly be able to enable the option by hand as well.

Defaulting to "n" (the default) means causing regressions when these
few people use an existing defconfig.

Having "dfault y if !DRM" makes sense to me. I guess is a corner case but
at least it won't silently be disabled for users that only want fbdev as
Geert mentioned.

I wouldn't call it a regression though, because AFAIK the Kconfig options
are not a stable API ?

quoted

quoted

Or reserve "FB" for real fbdev drivers, and introduce a new FB_CORE,
to be selected by both FB and DRM_FBDEV_EMULATION?
Then FB_DEVICE can depend on FB_CORE, and default to y if FB.

Funny that you mention because it's exactly what I attempted in the past:

https://lore.kernel.org/all/20210827100531.1578604-1-javierm@redhat.com/T/#u (local)

quoted

That wouldn't work. In Tumbleweed, we still have efifb and vesafb
enabled under certain conditions; merely for the kernel console. We'd
have to enable CONFIG_FB, which would bring back the device.

"Default y" does not mean that you cannot disable FB_DEVICE, so
you are not forced to bring back the device?

I think we can have both to make the kernel more configurable:

1) Allow to only disable fbdev user-space APIs (/dev/fb?, /proc/fb, etc),
   which is what the series is doing with the new FB_DEVICE config symbol.

2) Allow to disable all "native" fbdev drivers and only keep the DRM fbdev
   emulation layer. That's what my series attempted to do with the FB_CORE
   Kconfig symbol.

I believe that there are use cases for both, for example as Thomas' said
many distros are disabling all the fbdev drivers and their user-space only
requires DRM/KMS, so makes sense to not expose any fbdev uAPI at all.

But may be that other users want the opposite, they have an old user-space
that requires fbdev, but is running on newer hardware that only have a DRM
driver. So they will want DRM fbdev emulation but none fbdev driver at all.

That's why I think that FB_DEVICE and FB_CORE are complementary and we can
support any combination of the two, if you agree there are uses for either.

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat