Date: Fri, 3 Oct 2014 10:30:51 +0200 From: Baptiste Daroussin <bapt@FreeBSD.org> To: ports@FreeBSD.org, stable@FreeBSD.org Subject: Removal of legacy X.Org (aka non-WITH_NEW_XORG) Message-ID: <20141003083051.GA52332@ivaldir.etoilebsd.net>
next in thread | raw e-mail | index | archive | help
--EVF5PPMfhYS0aIcm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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
Note official packages reflecting this sitation will start building on
Wednesday 8th of October and hit your mirrors as soon as possible for both
quarterly branch and regular head.
regards,
Bapt on behalf on the X11 team
--EVF5PPMfhYS0aIcm
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlQuXrsACgkQ8kTtMUmk6Ey8UQCeLqfukwHvHV3zcLLarN0ws9X/
tioAnj2/fnS14ANgaYUsVm0XBNNvQAE6
=PuNN
-----END PGP SIGNATURE-----
--EVF5PPMfhYS0aIcm--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141003083051.GA52332>