Re: [RFC] future of drm1 in base

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.

Regards,

On Mon, Sep 4, 2017 at 12:33 PM, Johannes M Dieterich <jmd_at_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-x11_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-unsubscribe_at_freebsd.org"