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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20141003/59700984/attachment.sig>
Jean-Sébastien Pédron
2014-Oct-03 08:56 UTC
Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG)
On 03.10.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 teamLet's forward this announcement to the freebsd-x11@ mailing-list. -- Jean-Sébastien Pédron
Jean-Sébastien Pédron
2014-Oct-03 08:56 UTC
Removal of legacy X.Org (aka non-WITH_NEW_XORG)
On 03.10.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 teamLet's forward this announcement to the freebsd-x11@ mailing-list. -- 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/704890e6/attachment.sig>
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
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 _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-10-03 10:30, Baptiste Daroussin wrote:> Hi, ><...>> 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<...> Hi, I'm running new X.Org with sc, and I have been doing so for quite some time, and I have no problem with console switching. Works perfectly. I'm using nvidia-driver-331.67_1, and perhaps that has got something to do with it? I haven't seen it mentioned on any pages and/or discussions about the new X.Org. I would like to use vt, however it doesn't respond to any keyboard input during boot, and since I'm using a geli encrypted root, it's imperative that I can use my keyboard before / is mounted. I'm still using a PS/2 keyboard, and the reason for that is that last time I tried a USB one, it didn't work during boot. Regards, Rolf Nielsen -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJULmd1AAoJEPJMW41Co4JgNZ8P/RUPpbC4JMHmmIhX5WlzZWf4 gHFgwjY9WXmlR64JZs8msHVfDjgANDtELpTIM5ynQYtsyztQB7XJUxZHDpQGv4Ua WKx7nVSTh7oTWI3RNkl1hdorunLVW8pkc97FJ4dyrYRZHnBGkiXXl/k8BcxmQTap 6kMHstbDkfmxk3CnlcJwbdvA6BXjUAGahUrxNLiVgkt2a/6WOV+B25deYM1xm2cO gce/Jkmw2XrYR1UyU8Qqgm7LmnS1ZRSWK69JBsU8OlR8bcCvSYN4cvTNEFvBgkG7 KWguG1cT3fYdf/ir383YgB1H5NufX4yIPdzdnO+rSlw33m5Y+8emwpSX4ONJ1ADM SNhsYPcNnyYx3uGQ2ou1HdLx2LTf+xDdjE3QryGf6LDOX+NisrmbriLNATyuiJT2 jvFVD17bVLCVta17xSBIMDLZbaX6W+3wTkbPSBnIWSQfnhYCMTyUvtVyka4qlFmo JpW3pd2FWKugfR0s7ApSqb7HpHIMa6sxER/Q6XBSeKBd6+vBCL/4CZVXPNgj2UxO sorBSEeyoGEgf4i50V+DKhkg0WSa+nHmW0QZI/FDC2KdGWIhlLKKMtIE5S24TCDL a3JLQDWmac1btDkvzIE4YFLTP4F0LelyEVXk0X7Y1l1mSlgLvNnsY0q6sjB+rDC0 w5PVnFJeyXrMUZuK8Q8o =Cg4P -----END PGP SIGNATURE-----
2014-10-03 11:01 GMT+02:00 Claude Buisson <clbuisson@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é _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
Jean-Sébastien Pédron
2014-Oct-03 09:24 UTC
Re: 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
> 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=vtUgh. We've just spent the last 4 mos. tooling up for a migration of all our 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 release schedule has effectively become: RELENG_8.4: June 30, 2015 ===> October 8, 2014 RELENG_9: December 31, 2016 ===> October 8, 2014 :( 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. Sincerely, disappointed.> > 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 > >_______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 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=vtUgh. We've just spent the last 4 mos. tooling up for a migration of all our 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 release schedule has effectively become: RELENG_8.4: June 30, 2015 ===> October 8, 2014 RELENG_9: December 31, 2016 ===> October 8, 2014 :( 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. Sincerely, disappointed.> > 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 > >
.....> 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.Has this happened ? I was expecting to see an ATI UMS port appeat, and for the non UMS port to move to version 7, but have been checking and I still get this: $ pkg search xf86-video-ati xf86-video-ati-6.14.6_4 xf86-video-ati-ums-6.14.6_4 The version in the new xorg respsiotory is xf86-video-ati-7.2.0_4 - did I misunderstand what was changing, or is this delayed for some reason ? thanks, -pete. _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
.....> 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.Has this happened ? I was expecting to see an ATI UMS port appeat, and for the non UMS port to move to version 7, but have been checking and I still get this: $ pkg search xf86-video-ati xf86-video-ati-6.14.6_4 xf86-video-ati-ums-6.14.6_4 The version in the new xorg respsiotory is xf86-video-ati-7.2.0_4 - did I misunderstand what was changing, or is this delayed for some reason ? thanks, -pete.