On Mon, Sep 04, 2017 at 01:28:38PM -0700, Kevin Bowling wrote: > I wasn't subscribed to -x11 earlier but do want to add some commentary > to this thread. > > The language describing these drivers in upstream is not at all > ambiguous WRT to how bad these are and Linux distributions have > dropped them: > > <cut> > menuconfig DRM_LEGACY > bool "Enable legacy drivers (DANGEROUS)" > depends on DRM && MMU > select DRM_VM > help > Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous > APIs to user-space, which can be used to circumvent access > restrictions and other security measures. For backwards compatibility > those drivers are still available, but their use is highly > inadvisable and might harm your system. > > You are recommended to use the safe modeset-only drivers instead, and > perform 3D emulation in user-space. > > Unless you have strong reasons to go rogue, say "N". > <cut> > > There seems to be some kind of misunderstanding that removing these > drivers is taking something away from users. I disagree. It does > _not_ deorbit HW support. We'd be giving users a supportable and > secure experience by dropping them. For 2d desktop it is likely that > a framebuffer is fast(er) as David states. On any reasonable CPU 3d > (like the server models people pointed out) may even be faster using > llvmpipe.
I don't disagree in principle with removing the drivers, but if it's done it should be done for a good reason. I addressed the issue of the KLD name collision below, but security concerns are a more valid motivation for removing them. OTOH, the legacy drivers are not included in GENERIC kernels, so we're effectively doing the same thing as upstream Linux by making them opt-in by default, albeit without the scary warning. > > Regards, > > On Mon, Sep 4, 2017 at 12:33 PM, Johannes M Dieterich <j...@freebsd.org> > wrote: > > > > > > > > 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 > > _______________________________________________ > > freebsd-...@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-x11 > > To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org" _______________________________________________ email@example.com mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"