Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG)
. 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-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG)
On 03.10.2014 17:45, Marat N.Afanasyev wrote: I think that old X stack should not be dropped until at least, GPU locking problem is resolved, what we can say about Xorg stability under FreeBSD if one should reset one's desktop every week or so with lots of lost files? I cannot really use KMS drivers at all because of this problem. I've lost enough data while trying to test radeon kms, and I cannot switch from old xorg to new one. Most GPU lockups on Radeon occur because Mesa 9.1 is way too old and doesn't work well at all for these cards. Mesa 10.x behaves *much* better. Unfortunately, we can't use Mesa 10.x on FreeBSD 9.x and FreeBSD 10.0, because the Intel driver lacks a required feature [1]. This kind of impossible situations happens because our time is limited. That's why we need to drop the old stack and spend the saved time to move forward. If you're willing to try Mesa 10.3.0, it's available from the experimental branch of our development ports tree: https://wiki.freebsd.org/Graphics#Development_repository From this branch, build: o graphics/libdrm o graphics/libglapi o graphics/libGL o graphics/dri o graphics/libEGL (if you have it installed) o graphics/libglesv2 (if you have it installed) Is it possible to build new xorg without kms and with old radeon driver? Yes, in the case of Radeon, you can use xf86-video-ati-ums (in place of xf86-video-ati) with xserver 1.12. There's no need to rebuild xserver. [1] https://wiki.freebsd.org/Graphics/Add_HW_context_support_to_i915 -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG)
On 03.10.2014 17:47, Chris H wrote: If I understand [you] correctly; I will be able to use the NEW Xorg in RELENG_9, and that [effectively] only the Intel drivers are affected? Yes, only Intel users are affected on FreeBSD 8.x. You'll be able to use new xorg on FreeBSD 9.x and 10.x equally. en re vt(4); I am experiencing issues with vt(4). I'm testing on 11-CURRENT. Specifically; [left-button drag] selecting text withing xterm, and [left+right click] pasting, causes the d character to be prefixed to the pasted test, and again, the d character is suffixed to the pasted text, and will repeat (infinitely) unless the backspace key is pressed to stop it. Has this been addressed? Yes, this was fixed in 11-CURRENT. 10.1-RELEASE will have the fix too. Lastly; As we are almost exclusively on nVidia based graphics, can we [safely] presume we are not affected by the XORG changes? Yes! -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
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 team Let's forward this announcement to the freebsd-x11@ mailing-list. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG)
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-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG)
2014-10-03 11:01 GMT+02:00 Claude Buisson clbuis...@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 on FreeBSD 10.0 using the nvidia-driver port (version 340.24) René ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
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 signature.asc Description: OpenPGP digital signature
Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG)
From: Baptiste Daroussin b...@freebsd.org 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 Does 10.1 with vt in text mode support _all_ the following in rc.conf? scrnmap=koi8-u2cp866u font8x16=cp866u-8x16 allscreens_flags=80x30 keymap=ru.koi8-r One of my workstations uses nvidia-driver-304-304.88_2 (the latest nvidia-driver 331.67 doesn't support my videochip), another xf86-video-vesa-2.3.3_4 (RC410 [Radeon Xpress 200/1100], 1280x1024). I use both X and virtual terminals. Locale: lang=ru_RU.KOI8-R What problems will I have without sc? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG)
On 3 October 2014 10:00, l...@lena.kiev.ua wrote: Does 10.1 with vt in text mode support _all_ the following in rc.conf? scrnmap=koi8-u2cp866u font8x16=cp866u-8x16 allscreens_flags=80x30 keymap=ru.koi8-r No, in text mode vt currently has support for cp437 only. vt(4) uses UTF-8 only right now, and the default font (for graphics mode) includes a fairly wide character set. Resolution switching is not yet provided; vt(4) uses the resolution chosen by the underlying driver. That is, vt_vga will use 640x480, i915kms uses the native panel resolution. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG)
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 Ugh. 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-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG)
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=vt Ugh. 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. 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 or gtk application segfaulting all the time. meaning that xorg 1.12 and xorg 1.7 makes pretty much no differences on intel 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 well. No changes here, with the previous, you do not need kms neither vt. regards, Bapt pgptW3R1sWzyY.pgp Description: PGP signature
Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG)
Jean-Sébastien Pédron wrote: 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. I think that old X stack should not be dropped until at least, GPU locking problem is resolved, what we can say about Xorg stability under FreeBSD if one should reset one's desktop every week or so with lots of lost files? I cannot really use KMS drivers at all because of this problem. I've lost enough data while trying to test radeon kms, and I cannot switch from old xorg to new one. Is it possible to build new xorg without kms and with old radeon driver? -- SY, Marat smime.p7s Description: S/MIME Cryptographic Signature
Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG)
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=vt Ugh. 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. 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 or gtk application segfaulting all the time. meaning that xorg 1.12 and xorg 1.7 makes pretty much no differences on intel 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 well. No changes here, with the previous, you do not need kms neither vt. Thank you _very_ much for the clarification, Baptiste. If I understand [you] correctly; I will be able to use the NEW Xorg in RELENG_9, and that [effectively] only the Intel drivers are affected? en re vt(4); I am experiencing issues with vt(4). I'm testing on 11-CURRENT. Specifically; [left-button drag] selecting text withing xterm, and [left+right click] pasting, causes the d character to be prefixed to the pasted test, and again, the d character is suffixed to the pasted text, and will repeat (infinitely) unless the backspace key is pressed to stop it. Has this been addressed?
Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG)
From: Jean-S?bastien P?dron dumbb...@freebsd.org NVIDIA users are not impacted by this change at all. x11/nvidia-driver-304 (for older videochips) too? the NVIDIA driver (like old Intel/AMD UMS drivers) takes care of restoring the GPU in a state that syscons can use (eg. VGA text mode on a PC). What about xf86-video-vesa? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
RE: Removal of legacy X.Org (aka non-WITH_NEW_XORG)
I hope this may be an additional data point. I also had grave issues with NEW_XORG. When I did experience a problem 99% of the time the computer locked up. My uptime was never more than a 24 hour period. No crash dumps, black screen, no keyboard light activity in toggling caps lock. However, on occasion Xorg would loop as reported in http://lists.freebsd.org/pipermail/freebsd-current/2014-June/050690.html I finally noticed that Xorg was complaining about xfdevhw not being available and so I installed the port. Since then zero lockups. I left the machine run with no additional update or changes for over one week without issue, and have since that time been updating Xorg and drivers without issue short of having to always re-install xf86-input-keyboard (and in past both xf86-input-keyboard and xf86-input-mouse). My current Xorg.log reports [ 486.836] (II) Loading sub module fbdevhw [ 486.836] (II) LoadModule: fbdevhw [ 486.836] (II) Loading /usr/local/lib/xorg/modules/libfbdevhw.so [ 486.836] (EE) LoadModule: Module fbdevhw does not have a fbdevhwModuleData data object. [ 486.836] (II) UnloadModule: fbdevhw [ 486.836] (II) Unloading fbdevhw [ 486.836] (EE) Failed to load module fbdevhw (invalid module, 0) [ 486.836] (WW) Falling back to old probe method for fbdev so why this apparently made a difference I do not understand. I am by no means an expert and this may not be relevant at all but this seems to be the right audience. This was my course of events and X11 still is working great for me. I can supply any additional information if requested, I am on X.Org X Server 1.12.4 / 10.1-BETA1 --mikej -Original Message- From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd-sta...@freebsd.org] On Behalf Of Marat N.Afanasyev Sent: Friday, October 03, 2014 11:45 AM To: Jean-Sébastien Pédron; Claude Buisson; Baptiste Daroussin; po...@freebsd.org; sta...@freebsd.org; freebsd-...@freebsd.org Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) Jean-Sébastien Pédron wrote: 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. I think that old X stack should not be dropped until at least, GPU locking problem is resolved, what we can say about Xorg stability under FreeBSD if one should reset one's desktop every week or so with lots of lost files? I cannot really use KMS drivers at all because of this problem. I've lost enough data while trying to test radeon kms, and I cannot switch from old xorg to new one. Is it possible to build new xorg without kms and with old radeon driver? -- SY, Marat GoPai.com | Facebook.com/PaymentAlliance CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4001 or notify us at PAI , Dept. 99, 6060 Dutchmans Lane, Suite 320, Louisville, KY 40205 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
