Hi Am 24.01.22 um 16:29 schrieb Helge Deller:
On 1/24/22 12:50, Javier Martinez Canillas wrote:On 1/24/22 12:33, Thomas Zimmermann wrote: [snip]Thoughts?I can't say I approve keeping fbdev alive, but... With fbdev emulation, every DRM driver is an fbdev driver too. So CONFIG_FB_DRIVER is somewhat misleading. Better add an option like CONFIG_FBCON_HW_SCROLLING and have it selected by the fbdev drivers that absolutely need HW acceleration. That option would then protect the rsp code.I'm not a fan of something like CONFIG_FBCON_HW_SCROLLING, but I'm not against it either. For me it sounds that this is not the real direction you want to go, which is to prevent that any other drivers take the framebuffer before you take it with simpledrm or similiar. CONFIG_FBCON_HW_SCROLLING IMHO just disables the (from your POV) neglectable accleration part. With an option like CONFIG_FB_DRIVER (maybe better: CONFIG_FB_LEGACY_DRIVERS) it's an easy option for distros to disable all of the legacy drivers from being built & shipped.
These drivers have been disabled by most distros a long time ago. Those that still remain are the generic, soon to be replaced, ones; and drivers for niche architectures where no DRM-based replacement exists.
If I run DRM with fbdev emulation, HW scrolling is unused, possibly buggy, and I'd want to not built it if possible. I guess that's what most distros would want as well. That's the use case for FBCON_HW_SCROLLING.
Best regards Thomas -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
