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
2014-10-03 11:01 GMT+02:00 Claude Buisson <clbuisson at orange.fr>:> 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. >> >> [...]NVIDIA does not exist in your world ?> > Nvidia (GeForce GT240M, old card indeed) works fine here with NEW_XORG onFreeBSD 10.0 using the nvidia-driver port (version 340.24) Ren?
Jean-Sébastien Pédron
2014-Oct-03 09:24 UTC
Removal of legacy X.Org (aka non-WITH_NEW_XORG)
On 03.10.2014 11:01, Claude Buisson wrote:> NVIDIA does not exist in your world ?Hi! You're right, we forgot to mention NVIDIA. The NVIDIA port installs its own bits from the kernel module to the specific libGL.so. The notion of "UMS/KMS" doesn't exist and the port is made to work with all versions of FreeBSD and X.Org server. Therefore, NVIDIA users are not impacted by this change at all. -- Jean-S?bastien P?dron -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20141003/d05bde4b/attachment.sig>