Date: Mon, 04 Sep 2017 19:33:37 +0000 From: Johannes M Dieterich <jmd@freebsd.org> To: Mark Johnston <markj@freebsd.org> Cc: freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: Re: [RFC] future of drm1 in base Message-ID: <20170904193337.Horde.Wm3jEJaHwm_CuvGbAmSToz8@www.poelloepaeae.de> In-Reply-To: <20170903191908.GA1259@bish>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Johnston – Sun., 3. September 2017 15:19
> On Sat, Sep 02, 2017 at 10:02:57PM -0400, Johannes M Dieterich wrote:
> > Dear current/x11,
> >
> > please CC me on responses.
> >
> > I am writing you on behalf of the FreeBSDDesktop team concerning the
> > future of drm1 in base.
> >
> > drm1 in base supports the following GPUs:
> > * 3dfx Banshee/Voodoo3+ (tdfx)
> > * ATI Rage 128 (r128)
> > * ATI Rage Pro (mach64)
> > * Matrox G200/G400 (mga)
> > * Savage3D/MX/IX, Savage4, SuperSavage, Twister, ProSavage[DDR] (savage)
> > * SIS 300/630/540 and XGI V3XE/V5/V8 (sis)
> > * VIA Unichrome / Pro (via)
> >
> > Since their original introduction up to 2010 these drivers have mostly
> > been maintained as part of larger cleanups. The newest hardware drm1
> > supports dates from 2004, if I am not mistaken, and most of the
> > hardware is AGP-based.
> >
> > With the introduction of graphics/drm-next-kmod which brings its own
> > drm.ko following the Linux notation, we are facing collisions between
> > these old drivers' drm.ko and the newer one.
>
> I don't think this is a real problem. The reason one currently needs to
> manually load the drm-next drm.ko (rather than just kldloading a driver
> and having it pick up the right drm.ko automatically) is that our drm.ko
> defines the same module ("drmn") as drm2.ko in the base system. So upon
> attempting to load a drm-next driver, the kernel uses the linker hints
> to load drm2.ko, which is incorrect. However, this can be addressed by
> simply bumping the drmn version in the port and modifying the drivers
> accordingly. I've submitted a 4-line PR which does exactly that. After
> that change, we can modify the pkg-message to omit drm.ko from the
> kld_list value. As a result, the name of our DRM module doesn't matter
> since users don't need to specify it, so the collision with drm1 isn't a
> problem.
>
> > We would like to hear if anybody still runs CURRENT on machines housing
> > the above GPUs and relies on drm1.
> >
> > If there are still a significant number of people running CURRENT on
> > this hardware in production, we would be willing to make a
> > graphics/drm-legacy-kmod port.
>
> With the PR I mentioned above, I think it's a non-issue to keep drm1 in
> the base system. Since there appear to be at least some users of those
> drivers, I really think it would be preferable to avoid removing them
> unless it's absolutely necessary.
Your proposed solution does work, thanks for providing it! Let's move this conversation to a later point in time then.
Johannes
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170904193337.Horde.Wm3jEJaHwm_CuvGbAmSToz8>