From owner-freebsd-x11@FreeBSD.ORG Sat Oct 18 13:43:47 2014 Return-Path: Delivered-To: x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB6A3D2; Sat, 18 Oct 2014 13:43:47 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 52E21F74; Sat, 18 Oct 2014 13:43:47 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s9IDhetp086874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Oct 2014 16:43:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s9IDhetp086874 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s9IDhe30086873; Sat, 18 Oct 2014 16:43:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 18 Oct 2014 16:43:40 +0300 From: Konstantin Belousov To: Tijl Coosemans Subject: Re: After the latest dri update X11 reports a KMS error with a Radeon card which previously worked just fine. Message-ID: <20141018134340.GI2153@kib.kiev.ua> References: <54425C31.2090100@gmail.com> <20141018144000.5e706e49@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141018144000.5e706e49@kalimero.tijl.coosemans.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: kwm@FreeBSD.org, "freebsd-x11@freebsd.org" , Jukka Ukkonen , Mike Harding X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 13:43:47 -0000 On Sat, Oct 18, 2014 at 02:40:00PM +0200, Tijl Coosemans wrote: > On Sat, 18 Oct 2014 15:25:21 +0300 Jukka Ukkonen wrote: > > Current version of pixman: 0.32.4 > > Before reporting problems, check http://wiki.x.org > > to make sure that you have the latest version. > > Markers: (--) probed, (**) from config file, (==) default setting, > > (++) from command line, (!!) notice, (II) informational, > > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > > (==) Log file: "/var/log/Xorg.0.log", Time: Sat Oct 18 14:25:50 2014 > > (==) Using config file: "/usr/local/lib/X11/xorg.conf" > > (==) Using system config directory "/usr/local/share/X11/xorg.conf.d" > > *(II) [KMS] drm report modesetting isn't supported.* > > > > Fatal server error: > > no screens found > > > > Please consult the The X.Org Foundation support > > at http://wiki.x.org > > for help. > > Please also check the log file at "/var/log/Xorg.0.log" for additional > > information. > > Please try the attached patch for graphics/libdrm. The library checks > hw.dri.0.modesetting sysctl to see if KMS is available before loading > the DRM kernel modules that provide that sysctl. > Index: graphics/libdrm/Makefile > =================================================================== > --- graphics/libdrm/Makefile (revision 371105) > +++ graphics/libdrm/Makefile (working copy) > @@ -3,6 +3,7 @@ > > PORTNAME= libdrm > PORTVERSION= 2.4.58 > +PORTREVISION= 1 > PORTEPOCH= 1 > CATEGORIES= graphics x11 > MASTER_SITES= http://dri.freedesktop.org/libdrm/ > @@ -32,6 +33,7 @@ > .if ${ARCH} == "amd64" || ${ARCH} == "i386" > CONFIGURE_ARGS+=--enable-libkms > PLIST_SUB+= KMS="" NOUVEAU="" > +EXTRA_PATCHES+= ${FILESDIR}/extra-xf86drmMode.c > .else > CONFIGURE_ARGS+=--disable-libkms > PLIST_SUB+= KMS="@comment " NOUVEAU="@comment " > Index: graphics/libdrm/files/extra-xf86drmMode.c > =================================================================== > --- graphics/libdrm/files/extra-xf86drmMode.c (revision 0) > +++ graphics/libdrm/files/extra-xf86drmMode.c (working copy) > @@ -0,0 +1,42 @@ > +--- xf86drmMode.c.orig 2010-09-08 14:23:39.000000000 +0200 > ++++ xf86drmMode.c 2011-07-18 18:59:11.000000000 +0200 > +@@ -774,38 +774,7 @@ > + if (found) > + return 0; > + #elif defined (__FreeBSD__) || defined (__FreeBSD_kernel__) > +- char kbusid[1024], sbusid[1024]; > +- char oid[128]; > +- int domain, bus, dev, func; > +- int i, modesetting, ret; > +- size_t len; > +- > +- ret = sscanf(busid, "pci:%04x:%02x:%02x.%d", &domain, &bus, &dev, > +- &func); > +- if (ret != 4) > +- return -EINVAL; > +- snprintf(kbusid, sizeof(kbusid), "pci:%04x:%02x:%02x.%d", domain, bus, > +- dev, func); > +- > +- /* How many GPUs do we expect in the machine ? */ > +- for (i = 0; i < 16; i++) { > +- snprintf(oid, sizeof(oid), "hw.dri.%d.busid", i); > +- len = sizeof(sbusid); > +- ret = sysctlbyname(oid, sbusid, &len, NULL, 0); > +- if (ret == -1) { > +- if (errno == ENOENT) > +- continue; > +- return -EINVAL; > +- } > +- if (strcmp(sbusid, kbusid) != 0) > +- continue; > +- snprintf(oid, sizeof(oid), "hw.dri.%d.modesetting", i); > +- len = sizeof(modesetting); > +- ret = sysctlbyname(oid, &modesetting, &len, NULL, 0); > +- if (ret == -1 || len != sizeof(modesetting)) > +- return -EINVAL; > +- return (modesetting ? 0 : -ENOSYS); > +- } > ++ return 0; > + #elif defined(__DragonFly__) > + return 0; > + #endif I confirm both the problem and diagnosis as well. After the update, I have to use something like 'kldload radeonkms && startx' to start X server. Re-applying the patch which pretends that KMS is supported unconditionally looks as a step back for me. The libdrm change was finally committed, and this is what must be done by userspace to ensure backward binary compatibilty with drm updates in kernel. Obvious correct solution is to load module before the check, or require the loaded module when X server starts. I have no idea how hard to implement option one is.