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. JohannesReceived on Mon Sep 04 2017 - 17:58:44 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:13 UTC