From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 26 13:15:55 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A69BC9E5 for ; Wed, 26 Jun 2013 13:15:55 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 29A15170B for ; Wed, 26 Jun 2013 13:15:54 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.7/8.14.7/ALCHEMY.FRANKEN.DE) with ESMTP id r5QDFqs8009318; Wed, 26 Jun 2013 15:15:52 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.7/8.14.7/Submit) id r5QDFqGt009317; Wed, 26 Jun 2013 15:15:52 +0200 (CEST) (envelope-from marius) Date: Wed, 26 Jun 2013 15:15:52 +0200 From: Marius Strobl To: mexas@bristol.ac.uk Subject: Re: sparc64 machfb: (EE) Unable to map mmio aperture. Invalid argument (22) Message-ID: <20130626131552.GO940@alchemy.franken.de> References: <20130625212559.GA3904@alchemy.franken.de> <201306260742.r5Q7gVu2067875@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201306260742.r5Q7gVu2067875@mech-cluster241.men.bris.ac.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 13:15:55 -0000 On Wed, Jun 26, 2013 at 08:42:31AM +0100, Anton Shterenlikht wrote: > > Finally, I gather from what I read in ports@ > in the last couple of weeks that the new Xorg is > unlikely to work on sparc64 ever and the "Ever" is the wrong word here; along with once a again fixing "old" Xorg as of before the last set of port updates, I made "new" Xorg build on !x86 but the result didn't look to promising on sparc64. I plan to look at getting the current "new" Xorg to work there once the patch for fixing the "old" one is committed. Some relatively simple things are good candidates for why "new" Xorg failed that miserably last time. On the other hand, something more fundamental might also be the culprit so it's unclear at this point how much effort it'll take to make it work on sparc64. > old (current) will no longer be supported > after a while, so future, say 2-3 years ahead > of X on sparc64 looks bleak, right? > IMO, the future of Xorg on FreeBSD looks bleak in general, mainly due to the fact that we currently lack the necessary passionate _and_ knowledgeable people for maintaining it. Don't get this wrong; kib@ certainly spent a tremendous effort on getting KMS to work for Intel graphics hardware. However, AFAIK the version that went into FreeBSD isn't exactly complete and was already rather "old" compared to what was in Linux at that time, with things having changed there considerably since then. Also, KMS in FreeBSD is largely unmaintained after the initial drop. The folks that currently maintain the Xorg ports certainly are rather active but, unfortunately, they simply are not of the same grade as f. e. anholt@ and rnoland@ were in the past. In other words, FreeBSD already is seriously behind Linux regarding infrastructure needed for Xorg and it would take quite some efforts to just catch up, let alone constantly keeping up with them. At least for me, the two main reasons demotivating work on Xorg are that a) the future of Xorg itself is questionable and b) Xorg constantly keeps removing support for older generations of hardware upstream. IMO, if we were to spend manpower on improving desktop support in FreeBSD effectively, we should leave Xorg alone and either work on getting Wayland to work the right way, i. e. without x86-specific hacks and shortcuts, _now_. Alternatively, porting OpenBSD's Xorg "fork" Xenocara in order to piggy-back on their superior support for desktop hardware - similar to all the drivers for WIFI chipsets we ported from them - also seems to be a good way forward to me. This is _not_ to say, that OpenBSD generally would be superior to FreeBSD, though :) Marius