Hi Am 24.01.22 um 12:10 schrieb Helge Deller: [...]
Here is my proposed way forward:
a) I will resend the patches which reverts the remove-fbcon-hardware-scolling patches
to the mailing lists. I'll adjust the stable tags and update the commit messages.
b) Then after some days I'll include it in the fbdev for-next git branch. That way it's
included in the various build & test chains.
c) If everything is working well, I'll push that change during the next merge window
for kernel 5.18. If problems arise we will need to discuss.
While the patches are in the fbdev git tree we should decide how to exclude code
which is not needed for DRM.
What about this proposal:
a) adding a Kconfig option like:
CONFIG_FB_DRIVERS - enable if you need the fbdev drivers. For DRM-only this should be disabled.
b) Add to every native fbdev driver a "depends on FB_DRIVERS" in the Kconfig files.
c) That way we can use "#if defined(CONFIG_FB_DRIVERS).." to exclude code in fbcon which
isn't needed by DRM.
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.
Best regards Thomas
Helge
-- 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
