Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-745-g95dd7bea33-fm-20230905.001-g95dd7bea
Mime-Version: 1.0
Message-Id: <9a7c7cb2-fa9e-4bf9-891b-ccd754d1fc25@app.fastmail.com>
In-Reply-To: <CAMuHMdW63WjidvAovqRz70bMgbLt4cSkOP1xSh7sEcqdwR3tOw@mail.gmail.com>
References: <20230911205338.2385278-1-arnd@kernel.org>
 <CAMuHMdWizKkuLEcv8sFFOWPib-0e1onCRuQEZm6OhV592VWUKQ@mail.gmail.com>
 <637afb25-8ee2-4188-9385-27ee6a97ec59@suse.de>
 <CAMuHMdW63WjidvAovqRz70bMgbLt4cSkOP1xSh7sEcqdwR3tOw@mail.gmail.com>
Date:   Tue, 12 Sep 2023 05:04:37 -0400
From:   "Arnd Bergmann" <arnd@arndb.de>
To:     "Geert Uytterhoeven" <geert@linux-m68k.org>,
        "Thomas Zimmermann" <tzimmermann@suse.de>
Cc:     "Arnd Bergmann" <arnd@kernel.org>,
        "Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
        "Maxime Ripard" <mripard@kernel.org>,
        "Dave Airlie" <airlied@gmail.com>,
        "Daniel Vetter" <daniel@ffwll.ch>,
        "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
        "Helge Deller" <deller@gmx.de>,
        =?UTF-8?Q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>,
        "Dave Airlie" <airlied@redhat.com>,
        "Javier Martinez Canillas" <javierm@redhat.com>,
        "Jim Cromie" <jim.cromie@gmail.com>,
        "Sam Ravnborg" <sam@ravnborg.org>,
        "Arthur Grillo" <arthurgrillo@riseup.net>,
        dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
        linux-fbdev@vger.kernel.org
Subject: Re: [PATCH] drm: fix up fbdev Kconfig defaults
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Sep 12, 2023, at 04:18, Geert Uytterhoeven wrote:
> On Tue, Sep 12, 2023 at 10:11=E2=80=AFAM Thomas Zimmermann <tzimmerman=
n@suse.de> wrote:
>> Am 12.09.23 um 09:14 schrieb Geert Uytterhoeven:
>> [...]
>> >> --- a/drivers/gpu/drm/Kconfig
>> >> +++ b/drivers/gpu/drm/Kconfig
>> >> @@ -135,7 +135,7 @@ config DRM_FBDEV_EMULATION
>> >>          bool "Enable legacy fbdev support for your modesetting dr=
iver"
>> >>          depends on DRM
>> >>          select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_=
CONSOLE
>> >> -       default y
>> >> +       default FB
>> >
>> > While this is true for existing configs, it is no longer true in ge=
neral,
>> > as DRM_FBDEV_EMULATION is no longer related to FB.
>>
>> Would it make sense to make FRAMEBUFFER_CONSOLE an independent option
>> and have FBDEV_EMULATION depend on it? Something like this:
>>
>> FRAMEBUFFER_CONSOLE
>>         depends on DRM || FB
>>         select FB_CORE
>>
>> FBDEV_EMULATION
>>         depends on DRM
>>         depends on FRAMEBUFFER_CONSOLE
>>         default y
>
> Oops, now you can no longer have FBDEV_EMULATION without
> FRAMEBUFFER_CONSOLE, which is useful to be able to enable
> FB_DEVICE...
>
> And what's the point (if DRM is enabled) of having FB_CORE with
> FBDEV_EMULATION disabled?

I think we technically have the choice between selecting FB_CORE from
all the providers (FB and DRM_FBDEV_EMULATION) or from all the
consumers (FRAMEBUFFER_CONSOLE, FB_DEVICE and LOGO). We chose
to have it the former way at the moment, and I think what Thomas
suggests here is to change it to the latter.

The downside of the current approach is that you can have
pointless configuration with

CONFIG_FB=3Dy
CONFIG_DRM=3Dy
CONFIG_DRM_FBDEV_EMULATION=3Dy
CONFIG_FRAMEBUFFER_CONSOLE=3Dn
CONFIG_FB_DEVICE=3Dn
CONFIG_LOGO=3Dn

where the fb_core module gets initialized but it is impossible
for anything to draw on it.

Another option we have would be to try to separate the Kconfig
options for DRM and FB a little further, in anticipation of
reducing the amount of shared code in the long run (a lot of
FB code is built but never used when enabling console on
DRM).

So adding a new

config DRM_CONSOLE
     bool "enable console on DRM devices"
     depends on DRM
     depends on VT_CONSOLE
     depends on !UML
     select FB_CORE
     select FRAMEBUFFER_CONSOLE_CORE # new helper sym
     select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY
     default y

would give us a path to minimize the shared code
further, allowing the console code to be reused as
before, but without having to pull in the code that
is now only needed for FB_DEVICE. In this scenario,
we'd still have CONFIG_DRM_FBDEV_EMULATION like

config DRM_FBDEV_EMULATION
      bool "full emulation of fbdev layer for DRM"
      select FB_CORE
      select FB_DEVICE
      default FB # if enabled already, use it

but only use that if we actually want FB_DEVICE.

      Arnd