[PATCH 3/8] firmware: sysfb: Make CONFIG_SYSFB a user-selectable option
Javier Martinez Canillas
javierm at redhat.com
Fri Apr 24 09:24:07 PDT 2026
Thomas Zimmermann <tzimmermann at suse.de> writes:
Hello,
[...]
>>>>>> On Thu, Apr 2, 2026, at 11:09, Thomas Zimmermann wrote:
>>>>>> I don't really like this part of the series and would prefer
>>>>>> to keep CONFIG_SYSFB hidden as much as possible as an x86
I tend to agree with Arnd here, I'm also not seeing that much value on
making this symbol user selectable. For now I would just keep it hidden.
[...]
>> Yes, I saw that as well and don't have an immediate idea for how
>> to best do it. I saw that you already abstracted the access to
>> the screen_info members in drm_sysfb_screen_info.c, which I think
>> is a step in that direction.
>>
>> I also noticed that efidrm is mostly a subset of vesadrm, so
>> in theory they could be merged back into an x86 drm driver
>> along with the drm_sysfb_screen_info helpers, and have a non-x86
>> driver that constructs a drm_sysfb_device directly from the
>> EFI structures.
>
> I would not want to have a unifed driver for all-things-screen_info. The
> code that can easily be shared is already in the sysfb helpers. But I
> don't mind adding a separate driver for EFI's Graphics Output Protocol.
I agree. It is much more maintainable if we have dedicated DRM drivers that
use shared helpers, than attempting to have a driver for different platforms.
As Thomas explained, the maintance effort is small on the DRM side and he has
done a lot of work to split simpledrm in efidrm, vesadrm and ofdrm.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
More information about the linux-riscv
mailing list