Date: Fri, 15 May 2009 19:28:28 -0500 From: Robert Noland <rnoland@FreeBSD.org> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: freebsd-x11@freebsd.org Subject: Re: Whither X? Message-ID: <1242433708.5638.26.camel@balrog.2hip.net> In-Reply-To: <20090515232350.GH57001@server.vk2pj.dyndns.org> References: <20090515232350.GH57001@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-/nUy8WjXM5Wuf8/o2kmd Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2009-05-16 at 09:23 +1000, Peter Jeremy wrote: > Am I the only person who thinks the X.Org Project has lost its way (or > at least lost sight of its user community)? Ever since X.org 6.9, > successive releases of X.org have provided regressions and POLA > violations. >=20 > Whilst the X.Org Project has been adding native support for newer > GPUs, it has been doing so at the cost of basic functionality: If you > happen to be one of the lucky ones who gets the incantations and > sacrifices right then you might have accelerated 3D on your new > graphics card. More likely, it will hang your system if you try to > use it, or you won't be able to use X at all - even on cards that used > to work. >=20 > The transition from X.org 6.9 to X.org 7.0 added no new functionality. > It just split X into several hundred pieces and massively increased > the build time. The justification was that bugs in one component > could be corrected by just rebuilding that component. The reality has > been that the concepts of regression testing and integration testing > have gone out the door and new versions of arbitrary components (which > may or may not be API/ABI compatible with previous versions) are just > dumped on the user community. >=20 > The biggest regression in 7.0 was the switch from imake to GNU > configure. Whilst GNU configure is promoted as a portability aid, > anyone who attempts to port code to (eg) FreeBSD or Solaris will > quickly discover that the reality is completely the opposite - the > input language is so arcane it needs two levels of pre-processing by > custom tools before it can be handled by standard tools and it > generally provides a long-term, distributed memory for disinformation > (eg "the native object format for FreeBSD is a.out and objformat can > be used to check for ELF"). The appallingly bad performance of > configure (for some X components, configure takes 4-5 times as long to > run as the actual compilation), combined with the massive increase in > the number of pieces caused a massive increase in compilation time. > The FreeBSD performance was further worsened by the (known) poor > scaling of the packaging tools to large numbers of ports and > dependencies (stock xorg currently has ~250 build dependencies and > over 200 run dependencies). >=20 > X.org 7.1 was never commited into the ports tree and I don't have > any record of specific problems with X.org 7.2. >=20 > X.org 7.3 introduced another major set of regressions: > - hard-wired modelines that can't be disabled without patching the > source code (though this may be been broken earlier than 7.3). > - xdm config files installed into the wrong directory > - Broken files installed into /usr/local/lib/X11/xdm > - Corrupt xdm/Xresources file installed > - Display corruption when VTY/X11 switching on an ATI Radeon XPRESS 200M > - system clock occasionally loses a second during a VTY/X11 switch > - DPMS display off/on can corrupt display on ATI X200M. > - Use-after-free error causes Xserver to consistently abort() on exit > - Keyboard LEDs stopped working > - Scroll wheel stopped working > - HW cursor and DPMS broken on MGA G550 > - excessive gettimeofday() calls due to a configure bug >=20 > Many of them were subsequently fixed and some were problems in the > FreeBSD ports rather than the underlying X.org but it is unfortunate > that the code was committed to the ports tree before being fixed. >=20 > Somewhat after X.org 7.3 was committed, having followed the pain felt > by many others as well as having experienced problems myself, I wrote: > "Having followed X within FreeBSD from XFree86 3.1.2 through to X.org > 7.3, I can safely say that X.org 7.3 is by far the worst version as > far as POLA violations and regressions are concerned." >=20 > Well, that was before X.org 7.4 was released - which set a new record > for brokenness. >=20 > So far, X.org 7.x releases have focused on the server. X.org 7.4 adds > new client side functionality - with a new "Generic Event Extension". > Unfortunately, this was done before server support was ready - leading > to a stream of warnings that can't be suppressed. (I had a look at the > code and it is carefully crafted to make suppression almost impossible). >=20 > Another new misfeature in X.org 7.4 is the use of dbus/hal. I have > yet to find any rationale for using hal in an Xserver - hot-plugging > both keyboards and mice "just works" in FreeBSD and I've yet to see > any equipment that allows hot-plugging graphics cards. >=20 > Whilst trying to rebuild just parts of X, I've also discovered that > the dependency checks are wrong - eg, I can uninstall libxcb and all > its dependencies. When I then try to build xorg-server, it dies > inside the graphics/dri configure script reporting that x11-xcb is > missing. This shouldn't happen. >=20 > There were the usual POLA violations: > - xdm, xconsole, xload, xlsfonts, xmag (and others) were silently > dropped from x11-apps > - The "DontZap" default was quietly reversed, meaning Ctrl-Alt-BS no > longer works by default. > - Only one graphics card is supported. >=20 > But the worst problem is that for many people, including myself, the > Xserver just doesn't work at all. For the first time since at least > FreeBSD 2.x, FreeBSD 7.2 has shipped with an Xserver that won't work > for a significant number of people (as the mailing lists are beginning > to reveal). >=20 > 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. On occasion, I have managed to make the Xserver crash with > unresolved symbols (this appears to be the result of incorrect and/or > inadequate dynamic linkage information in some modules resulting in > required shared objects not being loaded in some cases). >=20 > And this occurs across a variety of hardware - i945, ATI X200M, ATI > Radeon HD2400, with both FreeBSD 7.2-stable and recent 8-current on > both i386 and amd64. I've tried building xorg from scratch both with > and without HAL. I've tried installing the Xorg packages that shipped > with FreeBSD 7.2 - and none of it works for me. >=20 > So far, the only thing I've found that works is to revert the > xorg-server and x11-drivers ports to 2009-Apr-01. (Though this leaves > me without DRI on my HD2400). >=20 > As I stated when the xorg 7.3 debacle was foisted on users: "Maybe the > Xorg sub-project needs to get some input from the Gnome and KDE > sub-projects. Both these groups manage to upgrade their ports without > regularly breaking everything." Unfortunately, nothing has been done > and xorg is now worse than ever. 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. Even with my hardware arsenal having improved dramatically in recent months, I am only one person... Some of the issues that you raise are Xorg in general, while some are porting issues. Since I don't see patches attached, I have to assume that you are ok with that. On the one hand you want drm/dri support for the HD2400, yet you don't seem to want any code changes. Intel is on the brink of just not working at all if I don't get at least GEM ported. I can not and will not try to do a full regression test on every card/driver that exists. Many drivers for older hardware are simply unmaintained and it's lucky if they still compile. Issues may be addressed with these drivers if they are raised, but if bugs aren't filed on freedesktop.org, then they just bitrot and die. 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 and while I agree that work could be done to help improve that situation either with documentation or additional work on the ports. I just simply can't do more than I'm doing now... Some of the POLA issues that you raise have been discussed on Xorg lists and have valid reasons for the changes, for at least some value of valid. 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? While this particular issue is being worked on again lately, the overall number of users that it effects is relatively small. While FreeBSD does support hot-plugging of mice via moused, it doesn't support any other types of input devices. It also doesn't allow for the individual input devices to have different properties or be managed independently for different screens or servers. The same goes for kbdmux. robert. --=20 Robert Noland <rnoland@FreeBSD.org> FreeBSD --=-/nUy8WjXM5Wuf8/o2kmd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkoOCKwACgkQM4TrQ4qfRONbSACfe7OX3g+mUUrhRfBUGXITuaiI 50MAn1VhGdGxpinM3OyZ2GkNblPlNCM8 =dchU -----END PGP SIGNATURE----- --=-/nUy8WjXM5Wuf8/o2kmd--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1242433708.5638.26.camel>