[PATCH 30/30] fbdev: Make support for userspace interfaces configurable

Fri Jun 9 07:29:37 UTC 2023

Hi Thomas,

On Fri, Jun 9, 2023 at 9:09 AM Thomas Zimmermann <tzimmermann at suse.de> wrote:
> Am 08.06.23 um 01:07 schrieb Javier Martinez Canillas:
> > Geert Uytterhoeven <geert at linux-m68k.org> writes:
> >> On Wed, Jun 7, 2023 at 5:15 PM Thomas Zimmermann <tzimmermann at suse.de> wrote:
> >>> Am 07.06.23 um 10:48 schrieb Geert Uytterhoeven:
> >>>> On Mon, Jun 5, 2023 at 4:48 PM Thomas Zimmermann <tzimmermann at suse.de> 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@redhat.com/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 at linux-m68k.org

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