From owner-freebsd-x11@FreeBSD.ORG Sat May 16 11:09:42 2009 Return-Path: Delivered-To: freebsd-x11@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 324C51065672; Sat, 16 May 2009 11:09:42 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id AB5448FC13; Sat, 16 May 2009 11:09:41 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-216-167.belrs3.nsw.optusnet.com.au [122.106.216.167]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n4GB9d2P015187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 May 2009 21:09:39 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n4GB9cgg016973; Sat, 16 May 2009 21:09:38 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n4GB9cBm016972; Sat, 16 May 2009 21:09:38 +1000 (EST) (envelope-from peter) Date: Sat, 16 May 2009 21:09:38 +1000 From: Peter Jeremy To: Robert Noland Message-ID: <20090516110938.GA16230@server.vk2pj.dyndns.org> References: <20090515232350.GH57001@server.vk2pj.dyndns.org> <1242433708.5638.26.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline In-Reply-To: <1242433708.5638.26.camel@balrog.2hip.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-x11@FreeBSD.org Subject: Re: Whither X? X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 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, 16 May 2009 11:09:42 -0000 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-May-15 19:28:28 -0500, Robert Noland wrote: >> The most common failure modes I've seen is that the Xserver just >> presents a completely blank screen - and all you can do is kill the >> Xserver. It turns out this is another POLA violation, rather than a broken X server. It seems that a totally blank/black screen is the new (poorly documented) standard and you need to use the '-retro' option to get anything to display by default. >You failed to mention that I am essentially the only person maintaining >Xorg, drm, Mesa (libGL, dri, etc...) and at least some subset of agp. Possibly because I wasn't aware. Given how important X is to desktop users, it's unreasonable to expect one person to carry the load (though, having said that, I can't offer to help because I've already over-committed my free time to other areas). I agree that you do an excellent job. My mail was written in frustration (and I know I'm not the only person who is frustrated with Xorg) at making no progress for more than a month. >months, I am only one person... Some of the issues that you raise are >Xorg in general, while some are porting issues. The most aggravating issue is the lack of documentation - the commit to xorg-apps made no mention of the removal of a large number of clients and neither did UPDATING. There has been no mention of the changes in X.org 7.4 (other than dribs and drabs here). It appears that the X11 Configuration chapter of the handbook was updated to cover Xorg 7.4 a couple of weeks ago but that wasn't mentioned here until today. > Since I don't see >patches attached, I have to assume that you are ok with that. I have previously provided patches to correct an Xserver bug (the PR is still open) and will continue to provide patches as I get time. I have also tested patches supplied by others where relevant and have previously requested that you circulate patchsets for testing major Xorg upgrades before committing them. I am happy to run experimental code and find/fix bugs when I know it's experimental. I'm not happy when I run what is supposed to be production code and it doesn't work as expected for no obvious reason. Unfortunately, my free time is limited and having wasted at least a week tracking down the latest POLA violation means I have lost a week of work that I could have used to write patches on Xorg or other projects I am trying to work on. > On the >one hand you want drm/dri support for the HD2400, yet you don't seem to >want any code changes. I am not saying that. I am saying that the Xorg project needs to stop breaking existing functionality and unnecessarily changing existing behaviour. Things like inverting the sense of "DontZap" or making the default screen blank with no cursor have no benefit and just waste people's time. > Intel is on the brink of just not working at all >if I don't get at least GEM ported. I've seen references to GEM (and messages about it not existing) but don't know anything about it. What is it and what is involved in porting it? > I can not and will not try to do a >full regression test on every card/driver that exists. I'm not expecting you to do this. It would be nice if the Xorg project did some regression testing though > Many drivers for >older hardware are simply unmaintained and it's lucky if they still >compile. I've not even tried using Xorg 7.4 on "older hardware" yet - my concern is that Xorg appear to be unnecessarily changing things (and this will obviously increase the risk of bitrot). >While we do experience some pain, I think that stating that "X just >doesn't work for a significant number of users" is a bit dramatic. Most >issues that I run across are pilot error It seems that Xorg 7.4 has made a number of radical changes to a large number of different areas - resulting in configuration options interacting in ways that are people aren't expecting. Whilst it could be called "pilot error", the lack of documentation doesn't help. I know I reported "blank screen on startup" and asked for help a month ago - whilst you did respond, you didn't actually mention that this was now the expected behaviour. > and while I agree that work >could be done to help improve that situation either with documentation I am not blaming you. XFree86 was fairly well documented. Unfortunately, most of the Xorg documentation was inherited from XFree86 and doesn't seem to have been touched since. An excellent example is the Xorg 7.4 page - http://www.x.org/wiki/Releases/7.4 - it contains a link to 'ChangeLog' but the target page doesn't exist. It talks about per-module changelogs but provides no indication as to how to find them. > The change to libpciaccess is what broke multi-card setups, but >would you argue that the xserver should be doing os specific frobbing of >the pci bus? This is a classic example of an unnecessary regression - the existing code worked but was replaced with new code that isn't ready yet. I agree that libpciaccess appears to be the way to go but it shouldn't be the default in a 'stable'/'production' release of Xorg until it provides at least equivalent functionality. >While FreeBSD does support hot-plugging of mice via moused, it doesn't >support any other types of input devices. Actually, hot-plugging keyboards _is_ supported and works according to some testing last night. > It also doesn't allow for the >individual input devices to have different properties or be managed >independently for different screens or servers. Well, due to the libpciaccess bungle, you can't have multiple servers any longer so that just leaves different screens. And I would suggest that the number of people who use input devices other than mouse or keyboard (note that these are the only devices installed by the xorg meta-port) and/or want them to have different properties for different screens is vanishingly small. --=20 Peter Jeremy --9amGYk9869ThD9tj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoOnvIACgkQ/opHv/APuIembACeKDeRedQwL1wNzk/HcwjY9wV7 HuwAoIPEwGF50sNwjFHRYXn7Hv2TQ0uB =/8pa -----END PGP SIGNATURE----- --9amGYk9869ThD9tj--