[RFC] Deprecation and removal of the drm2 driver

[Chris H]

On Mon, 21 May 2018 10:29:54 -0700 "Pete Wright" <pete at nomadlogic.org> said

> On 05/21/2018 10:07, Steve Kargl wrote:
> > On Mon, May 21, 2018 at 02:40:50AM +0300, Rozhuk Ivan wrote:
> >> On Sun, 20 May 2018 21:10:28 +0200
> >> Oliver Pinter <oliver.pinter at hardenedbsd.org> wrote:
> >>
> >>>> One of the reasons for the deprecation and removal of the drm2 bits
> >>>> is that they prevent us from automatically loading the
> >>>> drm-next/stable-kmod kernel modules, since the two collide.
> >>>> Regards
> >>>
> >>> Then it wold be better to resolve this problem, rather then removing a
> >>> working solution. What's about module versioning what in other cases
> >>> works?
> >>>
> >> May be just move old drm2 to ports?
> > Why?  "If it isn't broken, why fix it?"
> >
> > The conflict affects x86_64-*-freebsd aka amd64.  The
> > conflict does not affect any other architecture.  The
> > Makefile infrastructure can use MACHINE_ARCH to exclude
> > drm2 from build of amd64.
> >
> > I don't use netgraph or any of the if_*.ko modules.
> > Can we put all of that into ports?  I don't use any
> > scsi controllers, so those can go too.  Why make it
> > insanely fun for users to configure a FreeBSD system.
> to play devils advocate - why include a kernel module that causes 
> conflicts for a vast majority of the laptop devices that you can 
> purchase today (as well as for the foreseeable future), while forcing 
> the up to date and actively developed driver to not work out of the box?
> 
> IMHO it is issues like this (having out of date code that supports some 
> edge cases) which makes it harder for developers to dog-food the actual 
> OS they are developing on.  Having things work on modern hardware by 
> default seems like a great way to get more people on the platform 
> testing and bugfixing things.
> 
> The suggestion seems like a pretty good middle ground, people with older 
> devices will still have workable code while also making it easier to 
> continue to follow the state of the art in terms of hardware support.
> 
> -pete
Along the lines of Devils advocate;
Why do *any* <YOUR_FAVORITE_BRAND_HERE> get "special" attention?
Why does Intel get all the love? None of my nVidia cards get this; granted
they're blobs. But I've been waiting ~1yr. for support for my AMD GPU to be
supported.
IOW why not make all of them a port? IMHO vt(4) , while a nice *initial* effort.
Still falls *far* short of sc(ons). It's no big deal to whip up a custom kernel
with support for your chosen video card/APU/GPU. Then there can be less
complaints about "favoritism" -- everyone is treated equally. Why must the
stock (GENERIC) kernel support "graphics mode" out-of-the-box?
It appears to me; at this stage; or the *proposed* stage; that Intel will be
the only _well supported_ hardware out-of-the-box.

tl;dr;
Make all video cards/APU/GPU support come from ports/kernel OPTIONS_KNOBS

Thanks for your indulgence.

--Chris

> 
> -- 
> Pete Wright
> pete at nomadlogic.org
> @nomadlogicLA
> 
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"