WITH_NEW_XORG

The WITH_NEW_XORG ports knob enables the usage of a newer graphics stack (xserver 1.12, newer DDX and Mesa 9.1). For Intel and Radeon GPU, the new drivers require KMS support in the kernel.

The goal of this project is to enable this newer stack everywhere, to avoid the pain to maintain two stacks and finally move forward.

Short timetable for making the new xorg stack the default.

Subject: Removal of legacy X.Org (aka non-WITH_NEW_XORG)

Hello,

As you may know, the ports tree currently provides two versions of the X.Org server and related softwares:

1. xserver 1.7, Mesa 7.6 and libdrm 2.4.17
2. xserver 1.12, Mesa 9.1 and libdrm 2.4.52

We are about to remove the older set. The primary reason is the maintenance cost. The Graphics team is small and it's a nightmare to test changes. The consequence is infrequent updates to those softwares and, of course, way more work each time we decide to jump to a later version. All this time spent on keeping the legacy softwares in a working state isn't invested on improving the current softwares and today's hardware support.

The recent update to Cairo is a good example of this unsustainable situation: we tested what we could with the time we had and we sent a “Call for testers” on freebsd-x11@ and freebsd-current@ mailing-lists as well as asking for help on several Quarterly Status Reports. The benefit (if not the requirement) of the update and the lack of failure reports were instrumental in the final decision. Unfortunately, many users of the old X.Org server on Intel GPUs are now having crashes with any Gtk+ applications or the X.Org server itself. This time, we won't revert anything or spend more time on trying to fix the old stack.

Now, what does it change for the community? What are the benefits of this solution?

1. No more headache with WITH_NEW_XORG, alternate pkg(8) repository, mismatching ABI versions between xf86-input-* and xserver.
2. More frequent and independant updates (ie. no need to update the whole stack in one pass).
3. KDE and, in the near future, GNOME 3 available as packages in the main repository and on install medias.

Great, but what does it break?

The only regression is for users of Intel GPUs and FreeBSD 8.x and 9.0. Those versions of FreeBSD lack the required kernel driver and therefore xf86-video-intel won't work. Users can still use xf86-video-vesa if they can't/don't want to update their FreeBSD workstation.

There won't be any regression for owners of Radeon GPUs because xf86-video-ati 6.14.6 (the one with UMS support) will be provided in a separate port.

One proposition is to setup an alternate repository containing WITH_NEW_XORG packages.

Packages selected for this repository are:

• emulators/virtualbox-ose-additions
• graphics/dri
• graphics/libdrm
• graphics/libEGL
• graphics/libGL
• graphics/libglesv2
• x11/nvidia-driver*
• x11-drivers/xf86-*
• x11-servers/xorg-server
• x11/kde4
• x11/gnome3 (not yet in FreeBSD ports)

The make.conf file would be:

WITH_NEW_XORG=yes
WITH_GALLIUM=yes

To help with the discussion about WITH_NEW_XORG, here's a summary of what to expect depending on the FreeBSD version/X.Org server version/GPU combination:

1. A bit more explanation about VT switching. In this table, we mean:
   • Not supported: Only syscons is available in this case. When a user perform a VT-switch (using Ctrl+Alt+Fx keys combination) or exits from his X session, a black screen or the last image of his desktop (like a screenshot) will be presented to him. He can type commands blindly (eg. restart X after a crash) but without knowing this, he will surely believe his computer is frozen.
   • Works: When using vt(4), which is not yet the default anywhere and requires a manual step, VT switching works as expected: a console is presented to the user. When using syscons (ie. the default console driver), the behavior is exactly the same as in the “Not supported” case.
2. About Radeon up-to HD 4000 and kernels lacking the Radeon KMS driver, WITH_NEW_XORG currently pulls xf86-video-ati 7.x which requires a KMS driver. This means that, out-of-the-box, any Radeon GPU is unsupported. However, a user could manually install xf86-video-ati 6.14.x (the default one without WITH_NEW_XORG) and have a working xserver 1.12 with its Radeon HD 4000.