Messages in this thread | | | From | Javier Martinez Canillas <> | Subject | Re: [PATCH 1/2] fbdev: Split frame buffer support in FB and FB_CORE symbols | Date | Fri, 30 Jun 2023 14:22:04 +0200 |
| |
"Arnd Bergmann" <arnd@arndb.de> writes:
> On Fri, Jun 30, 2023, at 12:51, Javier Martinez Canillas wrote: >> "Arnd Bergmann" <arnd@arndb.de> writes: >> >>>> @@ -59,7 +71,7 @@ config FIRMWARE_EDID >>>> >>>> config FB_DEVICE >>>> bool "Provide legacy /dev/fb* device" >>>> - depends on FB >>>> + depends on FB_CORE >>>> default y >>>> help >>>> Say Y here if you want the legacy /dev/fb* device file and >>> >>> I don't see this symbol in linux-next yet, what tree are you using >>> as a base? >>> >> >> It's now in the drm-misc/drm-misc-next branch [1]. It's not in -next yet >> because it just landed a few days ago [2]. >> >> [1]: https://cgit.freedesktop.org/drm/drm-misc/log/?h=drm-misc-next >> [2]: https://cgit.freedesktop.org/drm/drm-misc/commit/?id=701d2054fa3 >> >> In fact, that's the reason why I rebased my previous attempt [0]. > > Ok. > > I wonder if it would make sense to also make FB_DEVICE depend on FB > instead of FB_CORE then. I don't think there is any actual dependency
No, because that wouldn't allow to have /dev/fb* devices when using the DRM fbdev emulation layer. It could be the case that users have an old fbdev user-space but the platform only has a DRM driver, in that case we want to disable all native fbdev drivers (CONFIG_FB not set) but still have FB_CORE, FB_DEVICE and DRM_FBDEV_EMULATION options enabled.
> between the two, but as I understand we want modern distros to use > neither FB nor FB_DEVICE, so tying them together with a dependency > may be desirable anyway. >
As said, modern distros would want to disable both FB and FB_DEVICE, but we want to allow for these two options to be {en,dis}abled independently.
> >>>> config FB_BACKLIGHT >>>> tristate >>>> - depends on FB >>>> + depends on FB_CORE >>>> select BACKLIGHT_CLASS_DEVICE >>> >>> Separating this one from FB_CORE would help avoid circular dependencies, >>> this one keeps causing issues. >>> >> >> You mean separating from FB or should I keep the existing depends on FB? >> >> It seems this is only used by fbdev drivers so probably the latter? > > Right, I meant keeping the dependency on FB. Ideally we'd > turn this all into a set of 'depends on' instead of 'select', > but that is a completely separate topic. >
Ok.
> Arnd >
-- Best regards,
Javier Martinez Canillas Core Platforms Red Hat
| |