Moving from XFree86 to X.Org

Thu, 15 Jul 2004 20:50:00 +0000

I moved a workstation from XFree86 to the X.Org server this week. The machine runs KDE all day and uses direct rendering, so my goal was not to celebrate a fork. It was to change the plumbing without making the desktop notice.

The reason for the move is now familiar. XFree86 4.4 adopted a licence clause that major free software distributors consider unacceptable or incompatible with how they combine software. X.Org X11R6.7 provides a continuation based on the earlier code and the broader development tree, under licences distributions are prepared to ship.

I let the distribution packages perform the replacement. This matters because the server is only one part of X: client libraries, fonts, loadable modules, drivers, and configuration paths must agree. Hand-installing a server over packaged files is an excellent way to create a system owned jointly by two package databases and nobody in particular.

Before upgrading, I saved the current X configuration and recorded the working video driver, horizontal and vertical monitor ranges, mouse protocol, keyboard layout, and enabled modules. I also made sure I could log in on a text console and knew how to stop the display manager.

The existing configuration required very little adjustment. Some installations use xorg.conf, while compatibility with an existing XF86Config may be provided. I prefer the new filename once the migration works; ambiguity is not a feature I need in emergency configuration.

The first test was a plain server start, followed by keyboard, mouse, resolution, and font checks. Then I tested KDE and direct rendering:

glxinfo | grep direct

That answer alone is not enough, but it quickly exposes a missing DRI module or mismatched userspace library. I also ran a 3D application and checked the X server log for modules that failed to load. A fast-looking spinning object is not a substitute for reading errors, though it is more festive.

Remote X clients and font paths deserve testing if the machine uses them. The wire protocol remains X11, but package changes can alter which font server or directories are configured. The migration should preserve capabilities, not just produce a local terminal window.

In normal use, KDE behaves exactly as it should: unexcited. Applications do not need to know whether the server came from XFree86 or X.Org. The visible result is deliberately boring.

The interesting change is organisational. Driver and extension work now has a development home tied more closely to the larger desktop community. That does not guarantee perfect engineering or rapid releases, but active collaboration is preferable to waiting behind a project boundary that many contributors had found difficult.

My advice remains to use distribution packages and retain a console escape route. This transition is technically conservative, but X sits underneath the entire graphical session. Even boring plumbing can flood the house when replaced casually.

Why XFree86 Is Being Replaced

Thu, 08 Apr 2004 21:05:00 +0000

X.Org released X11R6.7 this week, and several people have asked why distributions are considering it when XFree86 already drives their displays. The short answer is that a licensing dispute forced a technical fork to become an immediate practical choice.

XFree86 4.4 introduced a new licence clause requiring acknowledgement in advertising materials. Many free software projects and distributions consider that clause incompatible with the GNU General Public License or at least troublesome enough that they will not combine and ship the code as before. Debian and others had already objected; this is not a matter of one packager disliking a sentence’s punctuation.

The obvious response for a distribution is not to stop shipping X. X.Org’s release is based on the existing XFree86 code before the disputed licensing change, together with work from the freedesktop.org tree. It preserves the familiar X server and driver architecture while creating a place where development can continue under accepted licences.

For users, this is less dramatic than the project names suggest. KDE applications still speak X11. Existing XF86Config files are close to what the new server expects, although filenames and module paths may vary by package. Video, input, and font configuration remain recognisable.

I would test a replacement in this order:

console fallback works
server starts with the existing configuration
keyboard and mouse mappings are correct
native display resolution is available
direct rendering still works
KDE starts and restores a session

Direct rendering deserves special care because it joins the X server, a userspace library, a kernel module, and the video driver. Replacing one component can expose version mismatches that a basic desktop does not.

This split also reveals a governance problem. XFree86 had become difficult for outside developers to influence, and useful work was collecting elsewhere. A licence change was the trigger, but collaboration and release practice are part of why an alternative could form so quickly.

I dislike forks when they merely duplicate effort and rename directories. In this case the ecosystem needs a redistributable X implementation and a development home that distributions trust. X.Org is offering both while retaining the code and protocols users depend upon.

My advice is to follow the distribution rather than manually replacing a working server today. Packagers can coordinate drivers, libraries, paths, and upgrade scripts. The screen will still contain the same windows; the important change is who can maintain the machinery underneath them.

Xfree86 on Roberto Selbach

Moving from XFree86 to X.Org

Why XFree86 Is Being Replaced