Date: Sat, 14 Jul 2012 14:04:14 +0900 From: KIRIYAMA Kazuhiko <kiri@pis.elm.toba-cmt.ac.jp> To: x11@freebsd.org Subject: Re: [CFT] Xorg 7.7 ready for testing! Message-ID: <201207140504.q6E54E6G047414@pis.elm.toba-cmt.ac.jp> In-Reply-To: <CALBk6yJ2Tv=o0JyWjoWgW3E8o5ZFWXN9Y4TiJ41%2BMLx2=Uwujw@mail.gmail.com> References: <20120607203753.2466c63a.miwi@FreeBSD.org> <CALBk6yJ2Tv=o0JyWjoWgW3E8o5ZFWXN9Y4TiJ41%2BMLx2=Uwujw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At Thu, 7 Jun 2012 23:02:15 -0500, Brandon Gooch wrote: >=20 > On Thu, Jun 7, 2012 at 7:37 AM, Martin Wilke <miwi@freebsd.org> wrote: > > Hi Fans, > > > > The FreeBSD Xorg Team is pleased to announce Xorg 7.7 Release. We are > > very happy to be able to Call for testing shortly after the Xorg team > > annouced 7.7 release. This CFT is also open for discussion on how we > > should move forward with xorg release as we are facing some issues and > > we would like to ask for your opinion. Right now we have 2 existing > > xorg versions in our Ports Tree. The situation is quite bad due to our > > poor graphic card support. That means we do not have much choice but to > > take it as how it is now. But with regards to mesa support, we have to > > face some new challanges. > > > > With the new mesa 8.0 release, accelerated support for a number of > > older graphic cards was dropped. At the moment we are not sure how to > > deal with that.We are thinking of just replacing mesa 7.11 with 8.0 or > > making a new flag like WITH_MESA=3D 7.11.2 / 8.0 in combination with > > WITH_NEW_XORG, and let the mesa 7.6.1 set as default together with the > > old xorg version. Obviosly the latter option make the already complex > > situation more complex. The problem is, users, especially =A0the new on= es > > can easily get confused with it. Another issue is, the packages.We > > can't deliver a package set with the new Xorg releases. This means > > users with new hardware will have to compile everything by themselves. > > Though I'm totally fine with compiling, not everyone has the CPU power > > to compile everything. What I'm trying to say is, I would love to see > > the newer xorg released as the default version, but i know this will > > break a lot of old hardware. The thing is, when we want to try to > > become a Modern Operating System, I dont see any other way to make the > > new xorg as default but to give Users the chance to compile the old > > xorg with a flag like WITH_OLD_XORG. > > > > Some notes regarding KMS support: > > KMS Support has been completely migrated to FreeBSD 10. The MFC to 9 > > will come soon, that means so long its not MFC'd to 9-Stable, users > > need to get the latest patch from our x11 mailing list. I`ve made latest patch to 9-STABLE from [0] and put it on [1]. So I'd like to tested with [1] and make buildkernel but failed to compile to put out co= re with: cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=3Dc99 -g -Wal= l -Wredundant-decls -Wnested-externs -Wstrict-protot ypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -W= no-pointer-sign -fformat-extensions -Wmissing-inc lude-dirs -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys -I/usr/= src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTIO N_HEADERS -include opt_global.h -fno-common -finline-limit=3D8000 --param i= nline-unit-growth=3D100 --param large-function-growth=3D 1000 -fno-omit-frame-pointer -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno= -sse -msoft-float -fno-asynchronous-unwind-tables - ffreestanding -fstack-protector -Werror /usr/src/sys/vm/vm_contig.c cc1: warnings being treated as errors In file included from /usr/src/sys/vm/vm_contig.c:86: /usr/src/sys/vm/vm_phys.h:64: warning: redundant redeclaration of 'vm_phys_= fictitious_reg_range' [-Wredundant-decls] /usr/src/sys/vm/vm_phys.h:59: warning: previous declaration of 'vm_phys_fic= titious_reg_range' was here /usr/src/sys/vm/vm_phys.h:65: warning: redundant redeclaration of 'vm_phys_= fictitious_unreg_range' [-Wredundant-decls] /usr/src/sys/vm/vm_phys.h:60: warning: previous declaration of 'vm_phys_fic= titious_unreg_range' was here /usr/src/sys/vm/vm_phys.h:66: warning: redundant redeclaration of 'vm_phys_= fictitious_to_vm_page' [-Wredundant-decls] /usr/src/sys/vm/vm_phys.h:61: warning: previous declaration of 'vm_phys_fic= titious_to_vm_page' was here *** [vm_contig.o] Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. detail log has been put on [2]. 9.0-STABLE patched with [0] worked fine. Wh= ats wrong? [0] https://sites.google.com/site/junkkiri/drm-all.13.0-stable9.1.patch.new= ?attredirects=3D0&d=3D1 [1] https://sites.google.com/site/junkkiri/drm-all.13.0-stable9.1beta1.patc= h?attredirects=3D0&d=3D1 [2] https://sites.google.com/site/junkkiri/reconfig_s_k_20120714.log?attred= irects=3D0&d=3D1 > > > > This testing includes > > * libdrm 2.4.34 (including KMS support) > > * mesa 8.0.3 > > * full Xorg 7.7 release Change log > > =A0http://www.x.org/releases/X11R7.7/changelog.html > > > > Checkout Xorg Development Repo: > > You will need to install devel/subversion in order to checkout the xorg > > repo. Next, you will need to add WITH_NEW_XORG=3Dyes in > > your /etc/make.conf if you want to try out the new Xorg and mesa. Note > > that if you are not qualified for the KMS patch, you shouldn=92t use > > WITH_NEW_XORG=3Dyes because the old intel driver doesn=92t build with t= he > > new X server. If you are qualified, you should also set WITH_KMS=3Dyes > > in /etc/make.conf. Nvidia and ATI users should set WITH_NEW_XORG=3Dyes. > > > > svn co https://trillian.chruetertee.ch/svn/ports/trunk > > > > A small merge script to merge the svn checkout into the real portstree > > can be found here: > > > > http://people.freebsd.org/~miwi/xorg/xorgmerge > > > > The script is a modified version of the old kdemerge script. Please set > > the KDEDIR variable to the path of your X.org ports. After merging, run > > one of the following command, depending on which tool you use to manage > > your installed packages. > > > > portupgrade -af \* > > portmaster -a > > > > > > After installing these, you will have to rebuild all xf86-* ports. We > > will bump all releated ports during the commit to the ports tree. > > > > Roadmap: > > Our current plan is to let the CFT running for a while, and see what > > the outcome of the discussion above is. We hope to get a lot of > > feedback to solve as many problems as possible. Also we are working on > > the libglut to freeglut migration, this will definitely complete before > > we import Xorg 7.7. So we still have enough time. =A0We are looking > > forward for your feedback. > > > > - miwi on behalf of the FreeBSD X11 Team > > > > PS: Please reply only to x11@ thanks. > > >=20 > I just tried building on 10-CURRENT with clang, and ran into the issue > with the code in nouveau_array.c described here: >=20 > http://lists.freebsd.org/pipermail/freebsd-ports/2012-April/074582.html >=20 > Are there plans to fix this for this round of testing? >=20 > I generated the patch as per the follow-up message here: >=20 > http://lists.freebsd.org/pipermail/freebsd-ports/2012-April/074583.html >=20 > I'm retrying the build now, and if all goes well, I'll continue testing. >=20 > Thanks for the all of your hard work on Xorg! >=20 > -Brandon > _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" >=20 -kiri
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201207140504.q6E54E6G047414>