Date: Fri, 3 Oct 2014 17:29:30 +0200 From: Baptiste Daroussin <bapt@FreeBSD.org> To: Chris H <bsd-lists@bsdforge.com> Cc: ports@freebsd.org, stable@freebsd.org Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) Message-ID: <20141003152930.GC53855@ivaldir.etoilebsd.net> In-Reply-To: <af3d124817743a67c54e89d657a56b06.authenticated@ultimatedns.net> References: <20141003083051.GA52332@ivaldir.etoilebsd.net> <af3d124817743a67c54e89d657a56b06.authenticated@ultimatedns.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--PHCdUe6m4AxPMzOu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 03, 2014 at 07:47:23AM -0700, Chris H 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=3Dvt > Ugh. We've just spent the last 4 mos. tooling up for a migration of all o= ur > server farms from RELENG_8 --> RELENG 9. It would have only taken 1 mos. > but for pkg(8) debacle. Now, if I understand correctly. The current relea= se > schedule has effectively become: >=20 > RELENG_8.4: June 30, 2015 =3D=3D=3D> October 8, 2014 >=20 > RELENG_9: December 31, 2016 =3D=3D=3D> October 8, 2014 >=20 > :( >=20 > FWIW I'm looking forward to the NEW_XORG. But testing 11-CURRENT > indicates vt(4) isn't ready for prime time. Which makes it difficult > to justify it's requirement in RELENG. >=20 > Sincerely, > disappointed. No 8 is still supported and 9 as well, what you miss is that in any case the graphic stack with old xorg on Intel it anyway broken right now, X server o= r gtk application segfaulting all the time. meaning that xorg 1.12 and xorg 1.7 makes pretty much no differences on int= el on FreeBSD 8 and FreeBSD 9. For all other drivers xorg 1.12 works pretty well on FreeBSD 8 and FreeBSD = 9 as long as you do use the ums driver for ATI, nvidia work normally, vesa as we= ll. No changes here, with the previous, you do not need kms neither vt. regards, Bapt --PHCdUe6m4AxPMzOu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlQuwNoACgkQ8kTtMUmk6EwOTwCfagwMW8MrJzFhp2AeSw+D0wzN MW4AoLQYmEI5dKdjHLzoR0JYgeaBC6Xx =geiq -----END PGP SIGNATURE----- --PHCdUe6m4AxPMzOu--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141003152930.GC53855>