Date: Fri, 3 Oct 2014 08:47:11 -0700 (PDT) From: "Chris H" <bsd-lists@bsdforge.com> To: "Baptiste Daroussin" <bapt@FreeBSD.org> Cc: ports@FreeBSD.org, stable@FreeBSD.org, Chris H <bsd-lists@bsdforge.com> Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) Message-ID: <984afa8e5328e55b85c180a49e4ec544.authenticated@ultimatedns.net> In-Reply-To: <20141003152930.GC53855@ivaldir.etoilebsd.net> References: <20141003083051.GA52332@ivaldir.etoilebsd.net> <af3d124817743a67c54e89d657a56b06.authenticated@ultimatedns.net> <20141003152930.GC53855@ivaldir.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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? Lastly; As we are almost exclusively on nVidia based graphics, can we [safely] presume we are not affected by the XORG changes? Thank you again, Baptiste, for your thoughtful reply. --Chris > regards, > Bapt >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?984afa8e5328e55b85c180a49e4ec544.authenticated>