Date: Fri, 03 Oct 2014 11:01:58 +0200 From: Claude Buisson <clbuisson@orange.fr> To: Baptiste Daroussin <bapt@FreeBSD.org>, ports@FreeBSD.org, stable@FreeBSD.org Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) Message-ID: <542E6606.9050205@orange.fr> In-Reply-To: <20141003083051.GA52332@ivaldir.etoilebsd.net> References: <20141003083051.GA52332@ivaldir.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/03/2014 10:30, Baptiste Daroussin wrote: > 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 > NVIDIA does not exist in your world ? Claude Buisson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?542E6606.9050205>