From owner-freebsd-x11@FreeBSD.ORG Thu Aug 29 16:39:41 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B255B25F; Thu, 29 Aug 2013 16:39:41 +0000 (UTC) (envelope-from mrezny@hexaneinc.com) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by mx1.freebsd.org (Postfix) with ESMTP id 520A426CD; Thu, 29 Aug 2013 16:39:41 +0000 (UTC) Received: from mfilter11-d.gandi.net (mfilter11-d.gandi.net [217.70.178.131]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 744C6A80BC; Thu, 29 Aug 2013 18:39:23 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter11-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter11-d.gandi.net (mfilter11-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Rc+PX3-VKcUg; Thu, 29 Aug 2013 18:39:21 +0200 (CEST) X-Originating-IP: 89.24.3.53 Received: from unknown (53-3.gprs.tmcz.cz [89.24.3.53]) (Authenticated sender: mrezny@hexaneinc.com) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 3E9F7A80B1; Thu, 29 Aug 2013 18:39:20 +0200 (CEST) Date: Thu, 29 Aug 2013 18:39:29 +0200 From: Matthew Rezny To: Kevin Oberman Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering Message-ID: <20130829183929.00005478@unknown> In-Reply-To: References: X-Mailer: Claws Mail 3.9.0cvs98 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Thomas Mueller , "freebsd-x11@freebsd.org" , Niclas Zeising X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 16:39:41 -0000 On Wed, 28 Aug 2013 22:31:42 -0700 Kevin Oberman wrote: > On Wed, Aug 28, 2013 at 5:26 PM, Thomas Mueller > wrote: > > > > > From my previous post and Niclas Zeising's response: > > > > > > I had this type of problem with NetBSD 5.1_STABLE and 5.99.x > > > > even with > > native X that is part of the base system, as opposed to pkgsrc X. > > > I can't comment on how NetBSD does things, since I haven't used > > > it. > > > > You aren't missing anything, judging from my experience. FreeBSD is > > decidedly more advanced. > > > > > > I could return to a text console in the dark and type "shutdown > > > > -r > > now" or even type the command to go back into X, successfully. > > > In general, this can work. It did last time I tested, but that > > > was some time ago so things might have changed. > > > > When I tried with new Xorg and KMS in 9-STABLE, my system froze > > immediately, not just the console. I finally managed to downgrade > > to the old Xorg after considerable difficulty. > > > > I'd like to try again on a new computer, with FreeBSD-current/HEAD > > (10.0 is in the not-so-distant future?). > > > > With 3 TB hard drive and GPT, I have plenty of space and partitions > > to experiment, and probably less hazardous than the stablest > > versions of NetBSD. > > > > > > With serial ports becoming obsolete, what can one use for or in > > > > place > > of a serial console? > > > > > FireWire. I haven't tested myself, but have a look at > > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-dcons.html > > > for instructions on how to use FireWire as a console. > > > > This still leaves the question of how to set it up in terms of > > hardware. I don't think there are any FireWire consoles. > > > > Would I plug anything into the motherboard's FireWire port? I just > > thought of FireWire-to-HDMI cable but haven't looked to see if > > these exist. > > > > > > Would it work to have two xorg.conf files, one with Intel > > > > driver and > > the other with vesa? Then could you go back to a working console > > when using the vesa driver? > > > Once you've loaded the KMS awawre kernel module, there is no way > > > to get the console back short of a reboot of the system. > > > > But would starting X with vesa driver load the KMS awawre kernel > > module? > > > > What about "xorg -configure" which I might want to do the first > > time? > > > > > > I've wondered (call it X acrobatics) how to switch between root > > > > and > > nonroot, and between window managers, without going back to text > > console. > > > You could try some sort of desktop manager, such as gdm or kdm. > > > I've not used them on FreeBSD, but on linux they make it possible > > > to have several users logged into X at once, and switching window > > > manager, and so on. As for root, it is generally considered a > > > bad idea to run X as root. If it's just a root terminal you > > > need, you can always open an xterm (or your favorite terminal > > > emulator) and use su or sudo. Regards! > > > -- > > > Niclas Zeising > > > > On Linux (Slackware) I was only able to have one user at a time > > using xdm. > > > > But I remember one menu item in KDE was konsole as root user > > (konsole is KDE's X terminal). > > > > On NetBSD, xdm completely failed to run. > > > > But I got some ideas from Gentoo Linux emailing list, haven't tried > > yet. > > > > One very common mistake people make when attempting to use Intel > > KMS is to > either add the KMS driver to loader.conf or to load it manually after > booting. The result will be an immediate system lockup. Actually, I > suspect the system is not frozen, but the display is frozen and > nothing will accept keyboard or mouse input, so it looks frozen. > > Starting X will load the driver at the proper time so that X can > takeover the display, keyboard, and mouse properly. > > I might also note that Intel KMS requires: WITH_NEW_XORG, WITH_KMS, > and the build of graphics/libdrm with the KMS config option enabled. > > If I sent this to you in the past, sorry. I have posted this > information a few times and it may or may not make a difference for > you. I have not tried the Intel KMS as I have no applicable hardware, but I have read plenty of reports from people testing. I had assumed that when the KMS driver loads, it owns the video card and the kernel never gets to take it back. Does it also take over keyboard and mouse in some way? If so, that makes the problem worse and explains why some seem to have trouble getting a clean reboot/shutdown. I can't fathom why a video driver would take ownership of input devices. The VT switching issue doesn't seem like it should be a big one to solve. The kernel knows how to reinitialize the video card in text mode as it already relies on that to switch to a text console while UMS Xorg is running. I first thought the issue with KMS was simply that there was not a provision for the kernel to tell the KMS driver to give up the card. However, unloading the module still doesn't give the video card back so there is something more than meets the eye.