From owner-freebsd-current@freebsd.org Mon Sep 4 19:58:44 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F3421E1AB51; Mon, 4 Sep 2017 19:58:44 +0000 (UTC) (envelope-from jmd@freebsd.org) Received: from www.poelloepaeae.de (v22017034403546374.happysrv.de [188.68.38.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC3A28367E; Mon, 4 Sep 2017 19:58:44 +0000 (UTC) (envelope-from jmd@freebsd.org) Received: from mailman (www.poelloepaeae.de [192.168.1.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by www.poelloepaeae.de (Postfix) with ESMTPSA id D893D18811D; Mon, 4 Sep 2017 21:33:37 +0200 (CEST) From: Johannes M Dieterich To: Mark Johnston Cc: freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: Re: [RFC] future of drm1 in base In-Reply-To: <20170903191908.GA1259@bish> Message-ID: <20170904193337.Horde.Wm3jEJaHwm_CuvGbAmSToz8@www.poelloepaeae.de> User-Agent: Horde Application Framework 5 Date: Mon, 04 Sep 2017 19:33:37 +0000 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 19:58:45 -0000 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