Re: [RFC] Deprecation and removal of the drm2 driver

From: Joe Maloney <>
Date: Thu, 31 May 2018 11:34:18 -0400
I personally wish that more drivers, and firmware were separated from

For example wireless firmware:

That was a ticket which I chimed in on about a firmware I needed to make my
wireless adapter work.  I went through numerous efforts on IRC, and
elsewhere to try to bring attention that ticket in order to attempt to get
that firmware backported for several 10.x releases in a row without
success.  The firmware worked perfectly fine in PC-BSD where it was cherry
picked for numerous 10.x releases.

Technically since I was using PC-BSD, and was a committer for that project
I had no real dire need to reach out to FreeBSD about the issue.  I was
simply trying to help anyone else who might be encountering the same issue
trying to use stock FreeBSD because it was a simple backport.  If my effort
had turned out to be more fruitful I would have spent more time pursuing
tickets, diffs, or whatever to get more things back-ported when I found
them.  I am not sure where the breakdown was which did not allow that to
happen.  Anyways I don't want to bikeshed, or anything but I just wanted to
point out how I think having more drivers, and firmware in ports could be
helpful to enhance compatibility for end users.

Having a separate port for legacy drm could definitely make things easier
to providing installation options for end users, and automating the post
install action chosen in TrueOS, GhostBSD, and future derivative projects
tailored for the desktop use case.  For example for TrueOS we boot the
installer in failsafe mode with either VESA, or SCFB depending on whether
or not BIOS, or EFI is booted.  Then we could simply make a checkbox for
legacy intel, or skylake + to install the correct package then the module
path for either driver can more or less remain the same.  Eventually with
something like devmatch maybe that can even be fully automatic.

Joe Maloney

On Thu, May 31, 2018 at 10:23 AM, Daniel Eischen <>

> On Thu, 31 May 2018, Konstantin Belousov wrote:
> On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote:
>> We're not replacing anything. We are moving the older drm1 and drm2 from
>>> kernel to ports to make it easier for the majority of the users to load
>>> the
>>> correct driver without conflicts.
>> You do understand that you increase your maintainence load by this move.
>> dev/drm and dev/drm2 use KPIs which cannot be kept stable even in stable
>> branches, so you will need to chase these updates.
> I agree.  One argument previously made was that it's easier
> to maintain in ports.  One data point from me - I rarely
> update my ports, I update my OS much more frequently.  In
> fact, some times my ports get so out of date I just
> (take off and) nuke /usr/local (from orbit, it's the only
> way to be sure).
> Also, are we trying to solve a problem by moving drm[2] to
> ports that won't be a problem when base is pkg'ized?  If
> drm[2] is a package unto itself, then you don't have this
> problem of ports conflicting with it, at least not so
> much.  You can either not install the base drm[2] package
> or deinstall it to make way for a conflicting port.  Once
> drm[2] is pkg rm'd, it's not going to be reinstalled
> again when you update the base OS.
> And don't we have the same problem with sendmail and a
> few other base services?
> --
> DE
> _______________________________________________
> mailing list
> To unsubscribe, send any mail to ""
Received on Thu May 31 2018 - 13:34:20 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:16 UTC