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

Reply via email to