Whither X?

[Peter Jeremy]

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.

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.

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.

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).

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.

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

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.

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."

Well, that was before X.org 7.4 was released - which set a new record
for brokenness.

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).

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.

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.

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.

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).

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).

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.

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).

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.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20090515/78ce7c95/attachment.pgp