Make the building of drm dependent on MK_MODULE_DRM and the building
of module drm2 on MK_MODULE_DRM2. The defaults are unchanged.
Add big, nasty abandonware tags to this code.
Looks good, my minor nits can be ignored, up to you.
Oh, I see you changed the return code of the module load, I take it that is to lower its preference???
Isnt this actually 4 modules, drm2, i915kms, radeonkms and radeonkmsfw.
Here you do not enumerate the modules, and I see that this is 10 modules, I like consistency, can we just not enumerate in either case and just say:
meaning I think we can have i386 on equal footing via ports changes. LP64 is an accidental heuristic It may need to explode to #if arm, powerpc, and i386 if we dont finish in time? I think this would only be a string change here so it may be able to happen late in the release cycle if so?
No. It's the right heuristic now.
drm-stable-mod supports only 64-bit platforms. And that will not change.
This notice isn't used for the non-module drivers in the tree. After 12.0 goes out, we are removing all module builds, the intel driver and the radeon driver. We'll almost certainly move dev/drm2 to arm/dev/drm2 due to the difficulties at the current time with sharing (though there's much discussions about how arm might share, it's still not a done deal as far as a path forward as there's a lot of work there and no funding at the moment). Once we're there, it won't matter if thisis one way or another as I'll likely remove this code after the move. And for drm (not drm2) it won't matter at all: those will all be gone completely, barring issues with the port arising (the port is quite new, less than a week, so it is prudent to have a fallback plan until it's proven).
https://gist.github.com/strejda/c98e513c2ec1d2e23005bb66a7bc6399 suggests that it's quite hard to cope with the drm-next stuff, and maybe all drm due to the drm pager issue. If we take drm2 arm-only, then that could be fixed w/o harming other arch (because they would use something else).