Messages in this thread | | | From | Javier Martinez Canillas <> | Subject | Re: [PATCH v2 1/2] fbdev: Split frame buffer support in FB and FB_CORE symbols | Date | Mon, 03 Jul 2023 09:46:40 +0200 |
| |
Thomas Zimmermann <tzimmermann@suse.de> writes:
Hello Thomas,
Thanks for your review.
> Hi > > Am 01.07.23 um 23:44 schrieb Javier Martinez Canillas:
[...]
>> >> +menuconfig FB_CORE >> + tristate "Core support for frame buffer devices" > > With the text, this is visible; as others noted. >
Yes, I misremembered what made a Kconfig symbol non-visible, and thought that was just the lack of a help section but forgot to remove the prompt.
This is already fixed in v3.
>> + >> menuconfig FB >> - tristate "Support for frame buffer devices" >> + tristate "Support for frame buffer device drivers" > > Just keep the text as-is. >
I disagree. Because we are slightly changing the Kconfig symbol semantics here, for instance CONFIG_FB_CORE + CONFIG_DRM_FBDEV_EMULATION will also provide a frame buffer device (and with CONFIG_FB_DEVICE, will be exposed to user-space as a /dev/fb? device).
So now CONFIG_FB is really about allowing the native fbdev drivers to be enabled. That's why I'm changing the prompt text to make that more clear.
[...]
>> config FB_DEVICE >> bool "Provide legacy /dev/fb* device" >> - depends on FB >> + select FB_CORE > > This should depend on FB_CORE. >
Yes, already fixed in v3 too. I did a select to prevent symbol circular dependencies but doing that lead to CONFIG_FB_CORE=y even if CONFIG_DRM was set as a module.
But with the "select FB_CORE if DRM_FBDEV_EMULATION" in the DRM symbol as Arnd suggested, I was able to have FB_DEVICE to depend on FB_CORE again.
> Best regards > Thomas >
-- Best regards,
Javier Martinez Canillas Core Platforms Red Hat
| |