Date: Mon, 21 May 2018 11:05:56 -0700 From: "Chris H" <bsd-lists@BSDforge.com> To: "Pete Wright" <pete@nomadlogic.org> Cc: "Niclas Zeising" <zeising+freebsd@daemonic.se>, "FreeBSD X11 mailing list" <freebsd-x11@freebsd.org>, " Current FreeBSD" <freebsd-current@freebsd.org>, " Warner Losh" <imp@bsdimp.com>, " Oliver Pinter" <oliver.pinter@hardenedbsd.org>, <sgk@troutmask.apl.washington.edu>, "Rozhuk Ivan" <rozhuk.im@gmail.com> Subject: Re: [RFC] Deprecation and removal of the drm2 driver Message-ID: <b82e275f1c15b2e03bc26c3b3206d785@udns.ultimatedns.net> In-Reply-To: <a6a41f91-9fcf-b21d-2460-018118b5756e@nomadlogic.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 21 May 2018 10:29:54 -0700 "Pete Wright" <pete@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@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@nomadlogic.org > @nomadlogicLA > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b82e275f1c15b2e03bc26c3b3206d785>