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.

Project finished

WITH_NEW_XORG is enabled on all branches. The remaining usages will be removed with the next update to each port.

Roadmap

Short timetable for making the new xorg stack the default.

Task

Scheduled date

Actual date

Status

Comments

WITH_NEW_XORG by default for CURRENT

2013-12-16

DONE!

Prepare a list of packages for the WITH_NEW_XORG repository

2014-03-29

DONE!

Talk about desktop support deprecation on 8.x

Provide an alternate repository

2014-07-04

DONE!

WITH_NEW_XORG by default for 10

2014-03

2014-04-16

DONE!

WITH_NEW_XORG by default for 9

2014-03

2014-04-16

DONE!

WITH_NEW_XORG by default for 8

2014-03

2014-10-03

Superseeded by the removal of legacy xorg

Remove legacy xorg

2014-09

2014-12-22

DONE!

Announcement of the removal of legacy xorg

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

Hi,

As you may know, the ports tree currently provides two versions of the
X.Org server and related pieces of software:
   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 packages
and, of course, way more work each time we decide to jump to a later
version. All this time spent on keeping the legacy stack in a working
state isn't invested on improving the current one 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 (the last UMS-aware version
doesn't work with xserver 1.12). Users can still use xf86-video-vesa if
they can't/don't want to update their FreeBSD workstation. To install
xf86-video-vesa, run:
    pkg install xf86-video-vesa
or
    portmaster x11-drivers/xf86-video-vesa

There won't be any regression for owners of Radeon GPUs because
xf86-video-ati 6.14.6 (the last one with UMS support, which fortunately
works with xserver 1.12) is provided as a separate port. To install this
UMS driver:
    pkg install xf86-video-ati-ums
or
    portmaster x11-drivers/xf86-video-ati-ums

In the longer term, we suggest you update to FreeBSD 10.x (10.1-RELEASE
is around the corner). For example, you can find instructions to update
to 10.0-RELEASE here:
    https://www.freebsd.org/releases/10.0R/installation.html

Note that there's a know regression with syscons and kernel video
drivers: you can't switch back to a console once an X.Org session is
started. A new console driver called vt(4) fixes this issue while
bringing nice features. It's available in FreeBSD 9.3-RELEASE and
10.1-RELEASE but isn't enabled by default. To enable it, put the
following line in your /boot/loader.conf:
    kern.vty=vt

Alternate repositories

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

Packages selected for this repository are:

The make.conf file would be:

WITH_NEW_XORG=yes
WITH_GALLIUM=yes

Current situation

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:

This table is limited to the X.Org server version situation

It also assumes the xf86-video-* versions automatically chosen by the ports tree: this means KMS-only DDX for Intel and AMD GPUs.

The table doesn't show the following parameters:

  • our kernel (HEAD included) doesn't support most recent GPUs (eg. Intel Haswell or Radeon HD 8000+);
  • Mesa brings other problems (9.1 dropped support for some older GPUs, 9.2 doesn't support our ageing i915 KMS driver).

FreeBSD version

X.Org version

Vendor

GPU family

X.Org

VT switching (1)

Any

1.7

Intel

Up-to 2009

Works

Works

After 2009

Not supported

n/a

AMD

Up-to Radeon HD 4000

Works

Works

Radeon HD 5000+

Not supported

n/a

NVIDIA

Works

Works

Other vendors

Works

Works

8.x, 9.0

1.12

Intel

Up-to 2009

Not supported

n/a

After 2009

Not supported

n/a

AMD

Up-to Radeon HD 4000

It depends (2)

n/a

Radeon HD 5000+

Not supported

n/a

NVIDIA

Works

Works

Other vendors

Unknown

Works

9.1, 9.2

1.12

Intel

Up-to 2009

Works

Not supported

After 2009

Works

Not supported

AMD

Up-to Radeon HD 4000

It depends (2)

n/a

Radeon HD 5000+

Not supported

n/a

NVIDIA

Works

Works

Other vendors

Unknown

Works

10.0

1.12

Intel

Up-to 2009

Works

Not supported

After 2009

Works

Not supported

AMD

Up-to Radeon HD 4000

Works

Not supported

Radeon HD 5000+

Works

Not supported

NVIDIA

Works

Works

Other vendors

Unknown

Works

9.3, 10.1, HEAD

1.12

Intel

Up-to 2009

Works

Works

After 2009

Works

Works

AMD

Up-to Radeon HD 4000

Works

Works

Radeon HD 5000+

Works

Works

NVIDIA

Works

Works

Other vendors

Unknown

Works

  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.


CategoryHistorical

GraphicsOld/WITH_NEW_XORG (last edited 2018-11-26T01:31:35+0000 by PeteWright)