This patch series splits the fbdev core support in two different Kconfig
symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to
be disabled, while still having the the core fbdev support needed for the
CONFIG_DRM_FBDEV_EMULATION to be enabled. The motivation is automatically
disabling all fbdev drivers instead of having to be disabled individually.
The reason for doing this is that now with simpledrm, there's no need for
the legacy fbdev (e.g: efifb or vesafb) drivers anymore and many distros
now disable them. But it would simplify the config a lot fo have a single
Kconfig symbol to disable all fbdev drivers.
I've build tested with possible combinations of CONFIG_FB, CONFIG_FB_CORE,
CONFIG_DRM_FBDEV_EMULATION and CONFIG_FB_DEVICE symbols set to 'y' or 'n'.
Patch 1/2 makes the CONFIG_FB split that is mentioned above and patch 2/2
makes DRM fbdev emulation depend on the new FB_CORE symbol instead of FB.
Javier Martinez Canillas (2):
fbdev: Split frame buffer support in FB and FB_CORE symbols
drm: Make fbdev emulation depend on FB_CORE instead of FB
arch/x86/Makefile | 2 +-
arch/x86/video/Makefile | 2 +-
drivers/gpu/drm/Kconfig | 2 +-
drivers/video/console/Kconfig | 2 +-
drivers/video/fbdev/Kconfig | 62 ++++++++++++++++++-------------
drivers/video/fbdev/core/Makefile | 14 +++----
6 files changed, 48 insertions(+), 36 deletions(-)
--
2.41.0
Hi Javier
Am 30.06.23 um 00:51 schrieb Javier Martinez Canillas:
> This patch series splits the fbdev core support in two different Kconfig
> symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to
> be disabled, while still having the the core fbdev support needed for the
> CONFIG_DRM_FBDEV_EMULATION to be enabled. The motivation is automatically
> disabling all fbdev drivers instead of having to be disabled individually.
>
> The reason for doing this is that now with simpledrm, there's no need for
> the legacy fbdev (e.g: efifb or vesafb) drivers anymore and many distros
> now disable them. But it would simplify the config a lot fo have a single
> Kconfig symbol to disable all fbdev drivers.
I still don't get the point of this change. We've disabled the fbdev
drivers once. And they are off now and remain off.
The patchset now introduces FB_CORE, which just adds more options. But
you're not reducing the code or compile time or any thing similar.
I'd like to suggest a change to these patches: rather then making FB and
DRM_FBDEV_EMULATION depend on FB_CORE, make them select FB_CORE. That
will allow the DRM subsystem to enable framebuffer emulation
independently from framebuffer devices. If either has been set, the
fbdev core will be selected.
Best regards
Thomas
>
> I've build tested with possible combinations of CONFIG_FB, CONFIG_FB_CORE,
> CONFIG_DRM_FBDEV_EMULATION and CONFIG_FB_DEVICE symbols set to 'y' or 'n'.
>
> Patch 1/2 makes the CONFIG_FB split that is mentioned above and patch 2/2
> makes DRM fbdev emulation depend on the new FB_CORE symbol instead of FB.
>
>
> Javier Martinez Canillas (2):
> fbdev: Split frame buffer support in FB and FB_CORE symbols
> drm: Make fbdev emulation depend on FB_CORE instead of FB
>
> arch/x86/Makefile | 2 +-
> arch/x86/video/Makefile | 2 +-
> drivers/gpu/drm/Kconfig | 2 +-
> drivers/video/console/Kconfig | 2 +-
> drivers/video/fbdev/Kconfig | 62 ++++++++++++++++++-------------
> drivers/video/fbdev/core/Makefile | 14 +++----
> 6 files changed, 48 insertions(+), 36 deletions(-)
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
Thomas Zimmermann <[email protected]> writes:
Hello Thomas,
Thanks a lot for your review.
> Hi Javier
>
> Am 30.06.23 um 00:51 schrieb Javier Martinez Canillas:
>> This patch series splits the fbdev core support in two different Kconfig
>> symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to
>> be disabled, while still having the the core fbdev support needed for the
>> CONFIG_DRM_FBDEV_EMULATION to be enabled. The motivation is automatically
>> disabling all fbdev drivers instead of having to be disabled individually.
>>
>> The reason for doing this is that now with simpledrm, there's no need for
>> the legacy fbdev (e.g: efifb or vesafb) drivers anymore and many distros
>> now disable them. But it would simplify the config a lot fo have a single
>> Kconfig symbol to disable all fbdev drivers.
>
> I still don't get the point of this change. We've disabled the fbdev
> drivers once. And they are off now and remain off.
>
Yes, but doing that means you have a bunch of these in your kernel config:
#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_ARMCLCD is not set
...
I don't know how the kernel configuration management for the OpenSUSE
kernel package works, but at least in Fedora this translates to needing to
have a lot of explicit disable configurations in the form of:
$ cat redhat/configs/common/generic/CONFIG_FB_CIRRUS
# CONFIG_FB_CIRRUS is not set
$ ls redhat/configs/common/generic/CONFIG_FB_* | wc -l
61
I want to get rid of all those and the goal of this series is to reduce
that configuration to only:
$ cat redhat/configs/common/generic/CONFIG_FB
# CONFIG_FB is not set
$ cat redhat/configs/common/generic/CONFIG_FB_CORE
CONFIG_FB_CORE=y
> The patchset now introduces FB_CORE, which just adds more options. But
> you're not reducing the code or compile time or any thing similar.
>
No need for any redhat/configs/common/generic/CONFIG_FB_* because those
don't need to be explicitly disabled anymore since CONFIG_FB isn't set.
And the "Frame buffer hardware drivers" section in the .config goes away.
So it is a configuration simplification even when you can achieve the same
with the existing Kconfig symbols.
> I'd like to suggest a change to these patches: rather then making FB and
> DRM_FBDEV_EMULATION depend on FB_CORE, make them select FB_CORE. That
> will allow the DRM subsystem to enable framebuffer emulation
> independently from framebuffer devices. If either has been set, the
> fbdev core will be selected.
>
Yes, I guess that making it a non user-visible option makes sense. I'm
just wary of using select because I've bitten in the past by circular
dependencies when other symbol depends on it.
But I'm OK with that change and will do in v2.
> Best regards
> Thomas
>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Hi
Am 30.06.23 um 14:33 schrieb Javier Martinez Canillas:
> Thomas Zimmermann <[email protected]> writes:
>
> Hello Thomas,
>
> Thanks a lot for your review.
>
>> Hi Javier
>>
>> Am 30.06.23 um 00:51 schrieb Javier Martinez Canillas:
>>> This patch series splits the fbdev core support in two different Kconfig
>>> symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to
>>> be disabled, while still having the the core fbdev support needed for the
>>> CONFIG_DRM_FBDEV_EMULATION to be enabled. The motivation is automatically
>>> disabling all fbdev drivers instead of having to be disabled individually.
>>>
>>> The reason for doing this is that now with simpledrm, there's no need for
>>> the legacy fbdev (e.g: efifb or vesafb) drivers anymore and many distros
>>> now disable them. But it would simplify the config a lot fo have a single
>>> Kconfig symbol to disable all fbdev drivers.
>>
>> I still don't get the point of this change. We've disabled the fbdev
>> drivers once. And they are off now and remain off.
>>
>
> Yes, but doing that means you have a bunch of these in your kernel config:
>
> #
> # Frame buffer hardware drivers
> #
> # CONFIG_FB_CIRRUS is not set
> # CONFIG_FB_PM2 is not set
> # CONFIG_FB_ARMCLCD is not set
> ...
>
> I don't know how the kernel configuration management for the OpenSUSE
> kernel package works, but at least in Fedora this translates to needing to
> have a lot of explicit disable configurations in the form of:
>
> $ cat redhat/configs/common/generic/CONFIG_FB_CIRRUS
> # CONFIG_FB_CIRRUS is not set
>
> $ ls redhat/configs/common/generic/CONFIG_FB_* | wc -l
> 61
>
> I want to get rid of all those and the goal of this series is to reduce
> that configuration to only:
>
> $ cat redhat/configs/common/generic/CONFIG_FB
> # CONFIG_FB is not set
>
> $ cat redhat/configs/common/generic/CONFIG_FB_CORE
> CONFIG_FB_CORE=y
We have these 'is not set' lines on our kernel configs, but I don't
think they bother anyone too much.
Well, thanks for explaining. At least I now see why you want to do this
change.
>
>> The patchset now introduces FB_CORE, which just adds more options. But
>> you're not reducing the code or compile time or any thing similar.
>>
>
> No need for any redhat/configs/common/generic/CONFIG_FB_* because those
> don't need to be explicitly disabled anymore since CONFIG_FB isn't set.
>
> And the "Frame buffer hardware drivers" section in the .config goes away.
>
> So it is a configuration simplification even when you can achieve the same
> with the existing Kconfig symbols.
>
>> I'd like to suggest a change to these patches: rather then making FB and
>> DRM_FBDEV_EMULATION depend on FB_CORE, make them select FB_CORE. That
>> will allow the DRM subsystem to enable framebuffer emulation
>> independently from framebuffer devices. If either has been set, the
>> fbdev core will be selected.
>>
>
> Yes, I guess that making it a non user-visible option makes sense. I'm
> just wary of using select because I've bitten in the past by circular
> dependencies when other symbol depends on it.
>
> But I'm OK with that change and will do in v2.
Great, thanks.
Best regards
Thomas
>
>> Best regards
>> Thomas
>>
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
Andy Shevchenko <[email protected]> writes:
Hello Andy,
> On Fri, Jun 30, 2023 at 12:51:02AM +0200, Javier Martinez Canillas wrote:
>> This patch series splits the fbdev core support in two different Kconfig
>> symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to
>> be disabled, while still having the the core fbdev support needed for the
>> CONFIG_DRM_FBDEV_EMULATION to be enabled. The motivation is automatically
>> disabling all fbdev drivers instead of having to be disabled individually.
>>
>> The reason for doing this is that now with simpledrm, there's no need for
>> the legacy fbdev (e.g: efifb or vesafb) drivers anymore and many distros
>
> How does simpledrm works with earlycon=efi?
>
simpledrm isn't for earlycon. For that you use a different driver (i.e:
drivers/firmware/efi/earlycon.c). I'm just talking about fbdev drivers
here that could be replaced by simpledrm.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
On Fri, Jun 30, 2023 at 12:51:02AM +0200, Javier Martinez Canillas wrote:
> This patch series splits the fbdev core support in two different Kconfig
> symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to
> be disabled, while still having the the core fbdev support needed for the
> CONFIG_DRM_FBDEV_EMULATION to be enabled. The motivation is automatically
> disabling all fbdev drivers instead of having to be disabled individually.
>
> The reason for doing this is that now with simpledrm, there's no need for
> the legacy fbdev (e.g: efifb or vesafb) drivers anymore and many distros
How does simpledrm works with earlycon=efi?
> now disable them. But it would simplify the config a lot fo have a single
> Kconfig symbol to disable all fbdev drivers.
>
> I've build tested with possible combinations of CONFIG_FB, CONFIG_FB_CORE,
> CONFIG_DRM_FBDEV_EMULATION and CONFIG_FB_DEVICE symbols set to 'y' or 'n'.
>
> Patch 1/2 makes the CONFIG_FB split that is mentioned above and patch 2/2
> makes DRM fbdev emulation depend on the new FB_CORE symbol instead of FB.
--
With Best Regards,
Andy Shevchenko
On Fri, Jun 30, 2023 at 08:42:21PM +0300, Andy Shevchenko wrote:
> On Fri, Jun 30, 2023 at 07:38:01PM +0200, Javier Martinez Canillas wrote:
> > Andy Shevchenko <[email protected]> writes:
> > > On Fri, Jun 30, 2023 at 12:51:02AM +0200, Javier Martinez Canillas wrote:
...
> > >> The reason for doing this is that now with simpledrm, there's no need for
> > >> the legacy fbdev (e.g: efifb or vesafb) drivers anymore and many distros
> > >
> > > How does simpledrm works with earlycon=efi?
> > >
> >
> > simpledrm isn't for earlycon. For that you use a different driver (i.e:
> > drivers/firmware/efi/earlycon.c). I'm just talking about fbdev drivers
> > here that could be replaced by simpledrm.
>
> So, efifb can't be replaced. Please, fix your cover letter to reduce false
> impression of the scope of usage of the simpledrm.
Or tell how it can be used for earlycon on EFI platforms (if it can be).
--
With Best Regards,
Andy Shevchenko
On Fri, Jun 30, 2023 at 07:38:01PM +0200, Javier Martinez Canillas wrote:
> Andy Shevchenko <[email protected]> writes:
> > On Fri, Jun 30, 2023 at 12:51:02AM +0200, Javier Martinez Canillas wrote:
> >> This patch series splits the fbdev core support in two different Kconfig
> >> symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to
> >> be disabled, while still having the the core fbdev support needed for the
> >> CONFIG_DRM_FBDEV_EMULATION to be enabled. The motivation is automatically
> >> disabling all fbdev drivers instead of having to be disabled individually.
> >>
> >> The reason for doing this is that now with simpledrm, there's no need for
> >> the legacy fbdev (e.g: efifb or vesafb) drivers anymore and many distros
> >
> > How does simpledrm works with earlycon=efi?
> >
>
> simpledrm isn't for earlycon. For that you use a different driver (i.e:
> drivers/firmware/efi/earlycon.c). I'm just talking about fbdev drivers
> here that could be replaced by simpledrm.
So, efifb can't be replaced. Please, fix your cover letter to reduce false
impression of the scope of usage of the simpledrm.
--
With Best Regards,
Andy Shevchenko
Andy Shevchenko <[email protected]> writes:
> On Fri, Jun 30, 2023 at 07:38:01PM +0200, Javier Martinez Canillas wrote:
>> Andy Shevchenko <[email protected]> writes:
>> > On Fri, Jun 30, 2023 at 12:51:02AM +0200, Javier Martinez Canillas wrote:
>> >> This patch series splits the fbdev core support in two different Kconfig
>> >> symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to
>> >> be disabled, while still having the the core fbdev support needed for the
>> >> CONFIG_DRM_FBDEV_EMULATION to be enabled. The motivation is automatically
>> >> disabling all fbdev drivers instead of having to be disabled individually.
>> >>
>> >> The reason for doing this is that now with simpledrm, there's no need for
>> >> the legacy fbdev (e.g: efifb or vesafb) drivers anymore and many distros
>> >
>> > How does simpledrm works with earlycon=efi?
>> >
>>
>> simpledrm isn't for earlycon. For that you use a different driver (i.e:
>> drivers/firmware/efi/earlycon.c). I'm just talking about fbdev drivers
>> here that could be replaced by simpledrm.
>
> So, efifb can't be replaced. Please, fix your cover letter to reduce false
> impression of the scope of usage of the simpledrm.
>
Nothing to fixup.
You are conflating the efifb fbdev driver (drivers/video/fbdev/efifb.c)
with the efifb earlycon driver (drivers/firmware/efi/earlycon.c). I'm
talking about the former (which can be replaced by simpledrm) while you
are talking about the latter.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
On Fri, Jun 30, 2023, at 13:19, Thomas Zimmermann wrote:
> Am 30.06.23 um 00:51 schrieb Javier Martinez Canillas:
>> This patch series splits the fbdev core support in two different Kconfig
>> symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to
>> be disabled, while still having the the core fbdev support needed for the
>> CONFIG_DRM_FBDEV_EMULATION to be enabled. The motivation is automatically
>> disabling all fbdev drivers instead of having to be disabled individually.
>>
>> The reason for doing this is that now with simpledrm, there's no need for
>> the legacy fbdev (e.g: efifb or vesafb) drivers anymore and many distros
>> now disable them. But it would simplify the config a lot fo have a single
>> Kconfig symbol to disable all fbdev drivers.
>
> I still don't get the point of this change. We've disabled the fbdev
> drivers once. And they are off now and remain off.
>
> The patchset now introduces FB_CORE, which just adds more options. But
> you're not reducing the code or compile time or any thing similar.
>
> I'd like to suggest a change to these patches: rather then making FB and
> DRM_FBDEV_EMULATION depend on FB_CORE, make them select FB_CORE. That
> will allow the DRM subsystem to enable framebuffer emulation
> independently from framebuffer devices. If either has been set, the
> fbdev core will be selected.
I agree with making FB_CORE a hidden option that gets selected by FB
and DRM_FBDEV_EMULATION, without that we will get a whole lot of new
build regressions for people that don't update their defconfigs,
like we had when we removed the 'select FB' in DRM.
Aside from that, the changes look very useful to me.
Arnd
Andy Shevchenko <[email protected]> writes:
> On Fri, Jun 30, 2023 at 10:29:20PM +0200, Javier Martinez Canillas wrote:
>> Andy Shevchenko <[email protected]> writes:
>> > On Fri, Jun 30, 2023 at 07:38:01PM +0200, Javier Martinez Canillas wrote:
>> >> Andy Shevchenko <[email protected]> writes:
>> >> > On Fri, Jun 30, 2023 at 12:51:02AM +0200, Javier Martinez Canillas wrote:
>> >> >> This patch series splits the fbdev core support in two different Kconfig
>> >> >> symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to
>> >> >> be disabled, while still having the the core fbdev support needed for the
>> >> >> CONFIG_DRM_FBDEV_EMULATION to be enabled. The motivation is automatically
>> >> >> disabling all fbdev drivers instead of having to be disabled individually.
>> >> >>
>> >> >> The reason for doing this is that now with simpledrm, there's no need for
>> >> >> the legacy fbdev (e.g: efifb or vesafb) drivers anymore and many distros
>> >> >
>> >> > How does simpledrm works with earlycon=efi?
>> >> >
>> >>
>> >> simpledrm isn't for earlycon. For that you use a different driver (i.e:
>> >> drivers/firmware/efi/earlycon.c). I'm just talking about fbdev drivers
>> >> here that could be replaced by simpledrm.
>> >
>> > So, efifb can't be replaced. Please, fix your cover letter to reduce false
>> > impression of the scope of usage of the simpledrm.
>> >
>>
>> Nothing to fixup.
>>
>> You are conflating the efifb fbdev driver (drivers/video/fbdev/efifb.c)
>> with the efifb earlycon driver (drivers/firmware/efi/earlycon.c). I'm
>> talking about the former (which can be replaced by simpledrm) while you
>> are talking about the latter.
>
> Ah, this makes sense!
>
> I remember now that it was (still is?) an attempt to move from efifb to
> simpledrm, but have no idea what the status of that series is.
>
Indeed. And there was were also some patches IIRC to attempt porting the
earlycon efifb to a fbdev or DRM driver, can't remember now.
> --
> With Best Regards,
> Andy Shevchenko
>
>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
On Fri, Jun 30, 2023 at 10:29:20PM +0200, Javier Martinez Canillas wrote:
> Andy Shevchenko <[email protected]> writes:
> > On Fri, Jun 30, 2023 at 07:38:01PM +0200, Javier Martinez Canillas wrote:
> >> Andy Shevchenko <[email protected]> writes:
> >> > On Fri, Jun 30, 2023 at 12:51:02AM +0200, Javier Martinez Canillas wrote:
> >> >> This patch series splits the fbdev core support in two different Kconfig
> >> >> symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to
> >> >> be disabled, while still having the the core fbdev support needed for the
> >> >> CONFIG_DRM_FBDEV_EMULATION to be enabled. The motivation is automatically
> >> >> disabling all fbdev drivers instead of having to be disabled individually.
> >> >>
> >> >> The reason for doing this is that now with simpledrm, there's no need for
> >> >> the legacy fbdev (e.g: efifb or vesafb) drivers anymore and many distros
> >> >
> >> > How does simpledrm works with earlycon=efi?
> >> >
> >>
> >> simpledrm isn't for earlycon. For that you use a different driver (i.e:
> >> drivers/firmware/efi/earlycon.c). I'm just talking about fbdev drivers
> >> here that could be replaced by simpledrm.
> >
> > So, efifb can't be replaced. Please, fix your cover letter to reduce false
> > impression of the scope of usage of the simpledrm.
> >
>
> Nothing to fixup.
>
> You are conflating the efifb fbdev driver (drivers/video/fbdev/efifb.c)
> with the efifb earlycon driver (drivers/firmware/efi/earlycon.c). I'm
> talking about the former (which can be replaced by simpledrm) while you
> are talking about the latter.
Ah, this makes sense!
I remember now that it was (still is?) an attempt to move from efifb to
simpledrm, but have no idea what the status of that series is.
--
With Best Regards,
Andy Shevchenko