FreeBSD DRM Is Causing A Load Of In-Fighting This Week
It began by an announcement made back on 21 August that DRM/DRM2 has been removed from the upcoming FreeBSD 12.0 release. For Direct Rendering Manager kernel graphics driver support moving forward, users should use graphics/drm-legacy-kmod if running really old graphics hardware otherwise one of the drm-stable-kmod / drm-next-kmod / drm-devel-kmod options from FreeBSD Ports.
These newer FreeBSD DRM options are based upon their Linux kernel porting interface for getting the newer DRM driver code from the Linux kernel running in the FreeBSD space. That's in acknowledging the graphics drivers have become much more complex over the years with GPUs and there not being much in the way of FreeBSD graphics drivers on their own right and so across the BSD operating systems it's mostly been an effort about continually bringing over the latest open-source Linux kernel graphics drivers and adapting them to work with the BSD kernels -- or now this "KPI" porting/abstraction interface rather than trying to manually adjust these growing DRM drivers around BSD interfaces and coding preferences.
But that dropping of the FreeBSD DRM/DRM2 code was reverted on the reported grounds of not following FreeBSD's normal deprecation process. But according to the FreeBSD graphics team, they weren't provided with much guidance or documented "best practices" for handling this transition. But others have said that the code was reverted on the basis of the new FreeBSD DRM work not meeting "any standards of quality."
The FreeBSD graphics team was then accused of "working very hard to destroy the stability of FreeBSD just so that they can force their uncooked work down users throats."
The Linux KPI-based DRM code that is using the porting/abstraction interfaces for allowing more DRM code to run unmodified on FreeBSD is alleged by some to be "unstable at best, alpha level software that's constantly in need of someone to go and fix something on FreeBSD because Linux devs decided to make some changes or implement a new feature."
"This isn't a world where everyone gets a gold star, people fail even if they work very hard, failure is still an option. I guess the most important question to ask is what's the standards that the FreeBSD Foundation want to represent, uphold, and maintain?" wrote another commentator.
Some have also raised concerns how the migration of the FreeBSD DRM code to drm-legacy-kmod could impact existing users upgrading to FreeBSD 12. Of the non-heated messages in the thread, questions are mostly raised over the testing of this Direct Rendering Manager code and concerns over the upgrade process of existing FreeBSD users.
At this point it doesn't look like the Linux KPI-based DRM drivers are quite truly ready for FreeBSD 12.0 and their existing "legacy" DRM/DRM2 code will remain in place. FreeBSD 12.0 is expected for release in November.
This situation does show that those wanting to run FreeBSD on a desktop with accelerated graphics, using the NVIDIA proprietary driver is still the best option... NVIDIA is the only graphics driver vendor producing officially-supported driver releases for a BSD and it's mostly shared code across Linux/Windows/BSD/Solaris and thus largely of similar features and quality. It's mostly a trouble-free NVIDIA experience on FreeBSD and much better than using the often dated Intel/Radeon code ported from the Linux kernel. Though at least on the Intel side, they do have one of their Linux developers now focused on better FreeBSD hardware support.
60 Comments
