From owner-freebsd-x11@freebsd.org Mon May 21 18:09:21 2018 Return-Path: Delivered-To: freebsd-x11@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46C43EFB22E; Mon, 21 May 2018 18:09:21 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E00806A2CB; Mon, 21 May 2018 18:09:19 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id w4LI5oDk090972; Mon, 21 May 2018 11:05:56 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 Cc: "Niclas Zeising" , "FreeBSD X11 mailing list" , " Current FreeBSD" , " Warner Losh" , " Oliver Pinter" , , "Rozhuk Ivan" In-Reply-To: From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "Pete Wright" Subject: Re: [RFC] Deprecation and removal of the drm2 driver Date: Mon, 21 May 2018 11:05:56 -0700 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 18:09:21 -0000 On Mon, 21 May 2018 10:29:54 -0700 "Pete Wright" 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 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* 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= "