From owner-freebsd-x11@FreeBSD.ORG Tue Feb 18 19:15:40 2014 Return-Path: Delivered-To: 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 ESMTPS id A6E158C1; Tue, 18 Feb 2014 19:15:40 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 76EF418E5; Tue, 18 Feb 2014 19:15:40 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6A4E2B922; Tue, 18 Feb 2014 14:15:39 -0500 (EST) From: John Baldwin To: Kevin Oberman Subject: Re: NEW_XORG and vt(4) in stable branches Date: Tue, 18 Feb 2014 11:47:04 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201402121443.44313.jhb@freebsd.org> <1D7EC706-DFB5-40F8-8B4F-FF680E4F0FBB@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201402181147.05131.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 18 Feb 2014 14:15:39 -0500 (EST) Cc: FreeBSD Core Team , David Chisnall , Niclas Zeising , ray@freebsd.org, "freebsd-x11@freebsd.org" X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 19:15:40 -0000 On Friday, February 14, 2014 3:29:35 pm Kevin Oberman wrote: > On Fri, Feb 14, 2014 at 12:24 AM, David Chisnall wrote: > > > On 14 Feb 2014, at 02:12, Kevin Oberman wrote: > > > > > I'm just slightly confused by this. I am unaware of any reason that the > > use of NEW_XORG requires vt(4). KMS certainly does, but NEW_XORG should > > not, as far as I can tell. At least it does not on my system. I do believe > > that NEW_XORG will break some really old graphics cards, but I don't see > > how vt(4) will help this. > > > > > > Am I missing something? > > > > > > And I am very anxious to see vt(4) merged into 9 and 10, but I don't see > > how it impacts moving to NEW_XORG as default. > > > > KMS is required for several of the new drivers. Without KMS, NEW_XORG > > means Intel GPUs can only use VESA (the same is true for radeon, but the > > old radeon driver doesn't work at all with newer cards so it's not as much > > of a regression). With KMS and without vt(4), starting X means losing > > consoles. The only way to introduce NEW_XORG without introducing feature > > regressions is to have vt(4). This is why we asked the Foundation to fund > > the vt(4) work. > > > > Yes, I agre. I have an Intel GPU and it either must run KMS or VESA (which > really sucks). But, AFAIK, NEW_XORG does not break VESA, so making NEW_XORG > default regresses nothing. I am running with KMS and have no access to vtys > once I start X. I can see no regression from "It's broken" to "It's > broken". And VESA is pretty broken on it, though I lived with it for about > 9 months until the first release of KMS for testing on 9. > > Is it the case that NEW_XORG breaks syscons on some pre-Sandybridge systems > that would work with UMS but won't work with NEW_XORG? If that is the case, > I do understand. I was not aware of this issue. I believe there are older Intel GPUs that work without VESA with the old Xorg server (and can still switch vtys, etc.) that NEW_XORG would be a regression for. OTOH, I also want to push vt(4) to the stable branches in general as an option. I used NEW_XORG with KMS for a while without vt(4) and compared to all my previous experiences with X and laptops on FreeBSD, the lack of being able to exit X (or restart X to try to change settings, etc.) was quite a PITA. -- John Baldwin