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=2Eorg> 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=2Epinter@hardenedbsd=2Eorg> 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=2E > >>>> Regards > >>> > >>> Then it wold be better to resolve this problem, rather then removing = a > >>> working solution=2E 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=2E The > > conflict does not affect any other architecture=2E The > > Makefile infrastructure can use MACHINE_ARCH to exclude > > drm2 from build of amd64=2E > > > > I don't use netgraph or any of the if_*=2Eko modules=2E > > Can we put all of that into ports? I don't use any > > scsi controllers, so those can go too=2E Why make it > > insanely fun for users to configure a FreeBSD system=2E > to play devils advocate - why include a kernel module that causes=20 > conflicts for a vast majority of the laptop devices that you can=20 > purchase today (as well as for the foreseeable future), while forcing=20 > the up to date and actively developed driver to not work out of the box? >=20 > IMHO it is issues like this (having out of date code that supports some= =20 > edge cases) which makes it harder for developers to dog-food the actual= =20 > OS they are developing on=2E=C2=A0 Having things work on modern hardware by= =20 > default seems like a great way to get more people on the platform=20 > testing and bugfixing things=2E >=20 > The suggestion seems like a pretty good middle ground, people with older= =20 > devices will still have workable code while also making it easier to=20 > continue to follow the state of the art in terms of hardware support=2E >=20 > -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=2E But I've been waiting ~1yr=2E for support for my AMD GPU to be supported=2E IOW why not make all of them a port? IMHO vt(4) , while a nice *initial* ef= fort=2E Still falls *far* short of sc(ons)=2E It's no big deal to whip up a custom ke= rnel with support for your chosen video card/APU/GPU=2E Then there can be less complaints about "favoritism" -- everyone is treated equally=2E 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 b= e the only _well supported_ hardware out-of-the-box=2E tl;dr; Make all video cards/APU/GPU support come from ports/kernel OPTIONS_KNOBS Thanks for your indulgence=2E --Chris >=20 > --=20 > Pete Wright > pete@nomadlogic=2Eorg > @nomadlogicLA >=20 > _______________________________________________ > freebsd-current@freebsd=2Eorg mailing list > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd=2Eorg= "
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b82e275f1c15b2e03bc26c3b3206d785>