From owner-freebsd-current@freebsd.org Mon Sep 4 20:28:40 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 209EBE1C351 for ; Mon, 4 Sep 2017 20:28:40 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E61ABBD8 for ; Mon, 4 Sep 2017 20:28:39 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: by mail-oi0-x22b.google.com with SMTP id x184so11078084oia.0 for ; Mon, 04 Sep 2017 13:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kev009.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Jgay9rPnO14HSQ/WcPJ0NQaldbigf9JJtO2gDZjZDRY=; b=pYWVNPXQUIE90HlnKWc4s3lqgM8Z62h07qo6zD8DKGXvQ3cOgHDSIURmBiXdcoMh6g tqkhsP5iebATdE0hzPBQPik8dlBMEnYUdoHBlVYtlJymo1APD84oS+VadM/HdnbKHH0g PO2qrsW7WKyB2tdq99mwXOvn74HdBnraqwyJE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Jgay9rPnO14HSQ/WcPJ0NQaldbigf9JJtO2gDZjZDRY=; b=pBKOPSx4dhKTCdhsthENmJml70ZGNGeRq6eU9p22fkf8VR/n/WVOXhqWJYi9Y6Jacf /clUA0DUuKQ6x4qtuf2n1Y99D6sil/6quPhKgGvU65218vYjDMh9r4rgtxVR2AN/+Jkh XP9QisoEHjMQk1QklNDcl+AZPFCqf48EqgXNspJXvNMD7iWBLTWSP7jDnRclk2wYsnQ3 GB58EB6I9SdQ2uZkyvjbXsVaIvnaOTXSK1BcSRWbDapvDDBNVKQRx2RtRViqGUcUtcJP QzGX3Q/fcm4zTz3ny01jPk6q5Sg/LTcp2fjzN+vxdkn3onE/GeeQgVRDOD8t+0VKapM9 xktQ== X-Gm-Message-State: AHPjjUgGfPqmx1ZA8mGj/6oSJFtTTg3Se0AhAybMwa8Gnrezd/W/0zpu AmKP5ztp5piRHMMZQ6SoQ/Off4sbTdng X-Google-Smtp-Source: ADKCNb73R9JyFWWdScV0BQTT6Kg9BEYiFz2K1kGcNSpXwUzv30RhHXVdvnQQoylY9z7rJYK3UJhe4sDWL9ZtyF80yHU= X-Received: by 10.202.85.19 with SMTP id j19mr1406865oib.197.1504556918925; Mon, 04 Sep 2017 13:28:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.57.165 with HTTP; Mon, 4 Sep 2017 13:28:38 -0700 (PDT) In-Reply-To: <20170904193337.Horde.Wm3jEJaHwm_CuvGbAmSToz8@www.poelloepaeae.de> References: <20170903191908.GA1259@bish> <20170904193337.Horde.Wm3jEJaHwm_CuvGbAmSToz8@www.poelloepaeae.de> From: Kevin Bowling Date: Mon, 4 Sep 2017 13:28:38 -0700 Message-ID: Subject: Re: [RFC] future of drm1 in base To: Johannes M Dieterich Cc: Mark Johnston , freebsd-x11@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 20:28:40 -0000 I wasn't subscribed to -x11 earlier but do want to add some commentary to this thread. The language describing these drivers in upstream is not at all ambiguous WRT to how bad these are and Linux distributions have dropped them: menuconfig DRM_LEGACY bool "Enable legacy drivers (DANGEROUS)" depends on DRM && MMU select DRM_VM help Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous APIs to user-space, which can be used to circumvent access restrictions and other security measures. For backwards compatibility those drivers are still available, but their use is highly inadvisable and might harm your system. You are recommended to use the safe modeset-only drivers instead, and perform 3D emulation in user-space. Unless you have strong reasons to go rogue, say "N". There seems to be some kind of misunderstanding that removing these drivers is taking something away from users. I disagree. It does _not_ deorbit HW support. We'd be giving users a supportable and secure experience by dropping them. For 2d desktop it is likely that a framebuffer is fast(er) as David states. On any reasonable CPU 3d (like the server models people pointed out) may even be faster using llvmpipe. Regards, On Mon, Sep 4, 2017 at 12:33 PM, Johannes M Dieterich wro= te: > > > > Mark Johnston =E2=80=93 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] (savag= e) >> > * 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 housin= g >> > 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 thi= s conversation to a later point in time then. > > Johannes > _______________________________________________ > freebsd-x11@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org"