Hi Thomas, On Fri, Jun 9, 2023 at 9:09 AM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote: > Am 08.06.23 um 01:07 schrieb Javier Martinez Canillas: > > Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> writes: > >> On Wed, Jun 7, 2023 at 5:15 PM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote: > >>> Am 07.06.23 um 10:48 schrieb Geert Uytterhoeven: > >>>> On Mon, Jun 5, 2023 at 4:48 PM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote: > >>>>> --- 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. > > IMHO the rational behind such conditionals are mostly what "we make up > here in the discussion", but not something based on real-world feedback. > So I'd strongly prefer a clear n or y setting here. > > > > > I wouldn't call it a regression though, because AFAIK the Kconfig options > > are not a stable API ? > > IIRC in the past there have been concerns about changing Kconfig > defaults. If we go with "default n", we'd apparently do something similar. > > > > >>>> 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@xxxxxxxxxx/T/#u > > > >>> > >>> 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. > > I still don't understand the value of such an extra compile-time option? > Either you have fbdev userspace, then you want the device; or you > don't then it's better to disable it entirely. I don't see much of a > difference between DRM and fbdev drivers here. If you have DRM and are running a Linux desktop, you are probably using DRM userspace. If you have fbdev, and are using graphics, you have no choice but using an fbdev userspace. So with FB_CORE, you can have default y if you have a real fbdev driver, and default n if you have only DRM drivers. > I'd also question the argument that there's even fbdev userspace out > there. It was never popular in it's heyday and definitely hasn't > improved since then. Even the 3 people who still ask for fbdev support There's X.org, DirectFB, SDL, ... What do you think low-end embedded devices with an out-of-tree[*] fbdev driver are using? [*] There's been a moratorium on new fbdev drivers for about a decade. > here only seem to care about the performance of the framebuffer console, > but never about userspace. Unless you go for heavy graphics and 3D, a simple GUI with some buttons and text requires less performance than scrolling a full-screen graphical text console... > So I'd like to propose a different solution: on top of the current > patchset, let's make an fbdev module option that enables the device. If > CONFIG_FB_DEVICE has been enabled, the option would switch the > functionality on and off. A Kconfig option would set the default. With > such a setup, distributions can disable the fbdev device by default. > And the few users with the odd system that has fbdev userspace can still > enable the fbdev device at boot time. Hmm... That makes it even more complicated... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
