Hi Sam
Am 07.04.20 um 18:50 schrieb Sam Ravnborg:
Hi Thomas/Noralf.
Having DRM core take care of fbdev emulation was an idea Laurent had which was the spark that set me off making the generic fbdev emulation.
Maybe it's still too early to make this move, I don't know.
I think we should wait a bit. As you mentioned, there are drivers that have an fbdev bpp that differs from the preferred one. There might also be a chicken-and-egg problem with core and fb-helper modules.
Noralf - you had analyzed what drivers are (yet) to migrate to to the common fbdev emulation. Link: https://lore.kernel.org/dri-devel/34e654ae-0cc9-e393-ac02-e4ac6eda60f6@tronn...
armada
This one looks like its convertible to common infrastructure. Not just the fbdev console, but quite a bit of the framebuffer and GEM code. But I don't have the HW to test any patches.
gma500
I have a patch for replacing some of the gma500 code with common infrastructure. It currently fails and I haven't found time to look closer.
amd omapdrm nouveau i915 msm tegra exynos radeon rockchip
Maybe add this list to todo.rst - and if someone knows about it we could have a small description what is required before a driver can migrate. I can cook up the patch if anyone thinks this is useful.
I thought there already was such an entry in the TODO list. Some of these drivers have HW acceleration of some kind; although the benefits might be debatable. And there where 2 or 3 drivers with a design that is incompatible with generic fbdev. There's also some information at [1].
In any case, we should consider initializing each driver's fb console after registering the device. All console implementations would than act like DRM clients and less like driver components.
Best regards Thomas
[1] https://lore.kernel.org/dri-devel/7016126a-f498-1a4a-4721-c6305a961457@suse....
Sam