From owner-freebsd-x11@FreeBSD.ORG Thu Feb 13 09:22:43 2014 Return-Path: Delivered-To: x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D02A1B8; Thu, 13 Feb 2014 09:22:43 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D76701CB0; Thu, 13 Feb 2014 09:22:42 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id B828A40014; Thu, 13 Feb 2014 10:22:40 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id AA49740019; Thu, 13 Feb 2014 10:22:40 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (unknown [94.254.45.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 5848E40014; Thu, 13 Feb 2014 10:22:40 +0100 (CET) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3fPsh01BhZz8gh2; Thu, 13 Feb 2014 10:22:40 +0100 (CET) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([IPv6:2001:470:dca9:0:1::3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) (amavisd-new, port 10025) with ESMTPS id eleuzBsiH7rK; Thu, 13 Feb 2014 10:22:37 +0100 (CET) Received: from mail.daemonic.se (mail.daemonic.se [10.1.0.4]) by mx.daemonic.se (Postfix) with ESMTPS id 3fPsgx4Np8z8ggv; Thu, 13 Feb 2014 10:22:37 +0100 (CET) Received: from [IPv6:::1] (celes.daemonic.se [IPv6:2001:470:dca9:1::3]) by mail.daemonic.se (Postfix) with ESMTPSA id 3fPsgx3lxfz9CvV; Thu, 13 Feb 2014 10:22:37 +0100 (CET) Message-ID: <52FC8EDA.6090806@freebsd.org> Date: Thu, 13 Feb 2014 10:22:34 +0100 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: John Baldwin , x11@freebsd.org, ray@freebsd.org, Ed Maste Subject: Re: NEW_XORG and vt(4) in stable branches References: <201402121443.44313.jhb@freebsd.org> In-Reply-To: <201402121443.44313.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 140212-2, 2014-02-12), Outbound message X-Antivirus-Status: Clean X-Virus-Scanned: ClamAV using ClamSMTP Cc: FreeBSD Core Team 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: Thu, 13 Feb 2014 09:22:43 -0000 On 2014-02-12 20:43, John Baldwin wrote: > I just wanted to drop a note to see if everyone is on the same page here. I > know that core@ has been discussing the NEW_XORG internally quite a bit, but > that has all been internal to core@ so far. Good to know that it is being worked on. > > Our current feeling is that we would like to not enable NEW_XORG by default > for the packages for a given src branch until vt(4) has been merged to that > branch. We do not think that vt(4) needs to be enabled by default in the > branch; just having it available as an option as it is in HEAD would be > sufficient. Our understanding is that merging vt(4) in its current-ish form > to stable/10 and stable/9 is quite feasible and not a major nightmare. We do > not feel that it is necessary to merge to stable/8 as drm2 isn't merged to > stable/8 either. (Our assumption is that stable/8 will just stay with the old > Xorg and the ports tree will have to support old Xorg until 8.x support in > ports is EOL'd.) I understand your (core's) position on not wanting to enable NEW_XORG untill vt(4) is merged. I currently don't know status of such a merge, hopefully ray@ can fill in with that. stable/8 is getting harder and harder to maintain, at some point we will have to start breaking stuff, as will the kde team it sounds like. Of course we do our best not to do this. > > Does that sound sensible? Are any of our assumptions above incorrect? I don't know any details about how easy or hard it is to merge vt(4), but apart from that it sounds sensible. > > I know that on the Graphics page on the wiki, the x11@ team has a target date > of enabling NEW_XORG for stable branches (is that 9 and 10?) in March. Do we > think vt(4) can be merged to stable/10 and stable/9 before then? > March was picked as a target date mostly because of cario. graphics/cairo causes artifacts on some combinations of hardware (mostly intel it seems) when used with the old xorg. March was picked as a target date for kwm@ to merge gnome3, and gnome3 will need a recent cairo. I don't know about any plans for merging vt(4). With regards to cairo, we will probably have update that port anyway, regardless of the default version of xorg. There have been reports from gecko people (at least) about our old cairo causing issues as well, so no matter what we do some things will break. If we update cairo without switching xorg version, it is possible to change the NEW_XORG date to wait for a merge of vt(4). I hope this clears things up, otherwise please let me/us know! Regards! -- Niclas