Category Archives: xorg

[CFT] Xorg 7.7 ready for testing!

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= 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  the new ones 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.

This testing includes
* libdrm 2.4.34 (including KMS support)
* mesa 8.0.3
* full Xorg 7.7 release

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=yes 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’t use WITH_NEW_XORG=yes because the old intel driver doesn’t build with the new X server. If you are qualified, you should also set WITH_KMS=yes
in /etc/make.conf. Nvidia and ATI users should set WITH_NEW_XORG=yes.

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.  We are looking forward for your feedback.

– miwi on behalf of the FreeBSD X11 Team

[XORG-DEV] trunk is unstable

Dear All,
As I mentioned already in twitter/fb, our xorg-dev/trunk repo is currently
completely unstable because we are trying now to get xorg 7.7 RC ready. Our
wiki page will be updated soon. Testers and feedback are welcomed, but
please make sure you know what you are doing. If you like to discuss with
us directly, please join us on irc efnet/#freebsd-xorg.

– Martin

[CFT] Xorg Upgrade 7.5.2

The Xorg Team is pleased to announce the next round of Xorg updates. First of all, note that this is experimental, so you really have to know what you’re
doing read careful and follow exactly our documentation. We are specifically looking for feedback from Intel, ATI and NVIDIA users, we like to know if we break here
anything. The WITHOUT_NOUVEAU switch is gone along with xf86-video-nouveau, we suggest to switch to the nvidia blob.

KMS Support [1]:
Unfortunately, the intel KMS driver will only work for the latest FreeBSD 9-STABLE or 10-CURRENT users. The patch for HEAD current is named all.13.1.patch.
The higher the version the newer the patch is. Other needed patches are already available in the Xorg update.

HEAD Users:
Get the latest patchset from Kib here:
http://people.freebsd.org/~kib/drm/

9-STABLE Users:
Meowthink maintanice currently the backport to 9 STABLE, make sure you have the latest FreeBSD 9-STABLE src check out. Get the patch from here:
https://docs.google.com/leaf?id=0BxbPi2OX4_B-NWY3NWU3MzEtNDBjYy00NTljLThlZGItMWFlYjIyYjI4Yjk3&hl=en_US

Rebuild your Kernel and reboot.

Know issuse:
There will be a patch reject in the sys/dev/drm/i915_suspend.c file. The solution is to manually undo the expansion of the $FreeBSD: ….$ tag, so it only
says $FreeBSD$.

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=yes 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’t use WITH_NEW_XORG=yes because the old intel driver doesn’t build with the new X
server. If you are qualified, you should also set WITH_KMS=yes in /etc/make.conf.

svn co https://trillian.chruetertee.ch/svn/ports/tags/xorg_7_5_2

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 portstree.

Roadmap:
Our current plan is to let the CFT running until the last weekend of February. We hope to get a lot feedback to solve as many problems as possible.
So please help us to get the best xorg update ever in!

Links:
http://wiki.freebsd.org/Intel_GPU [1]
http://wiki.freebsd.org/Xorg
http://miwi.bsdcrew.de/2012/02/working-on-xorg-stuff/

Happy updating :)

– Miwi

Working on Xorg Stuff!

Hiho…

Well I know I haven’t been writing for a long time but there are always reasons behind it :). Lately I have been busy with my job and personal life, but anyway I’m still alive and I have started working on FreeBSD since a while.

As stated in the subject, why I’m writing today is to talk about FreeBSD Xorg stuff. Personally I have stopped working on it for a long time. The main reason was that we are still stuck on some problems like missing KMS/GEM support, though since a while there is some progress that can be seen. Also kwm@ and eadler@ jumped into the Xorg team and did a lot of good work in the last few months.

As a result, Xorg gets 2 layers of framework. What this means, users with newer GFX hardware will get the chance to use newer Xorg server and drivers. The team has decided to create a new flag called WITH_NEW_XORG that users have to include in /etc/make.conf. This was mainly done for the intel KMS work being done. It should probably work for other chips. Unfortunately, the intel KMS driver will only work on FreeBSD 9-stable or 10-CURRENT users. Older version of FreeBSD will not be supported. Intel users will need to patch their src manually with Kib’s KMS kernel patch to get the newer chips to work. We have libGL and Mesa patches in our xorg-dev repo ready.

Here are some facts on what you will get with WITH_NEW_XORG:

libdrm 2.4.30 (including KMS support)
mesa 7.11.2
xorg-server 1.10.4
a lot of new Graphic Drivers.

After this is done and committed we going to work on Mesa 8.0 and X server 1.12. The reason we haven’t done this yet is because they are in RC stage and x server 1.11 and above break the nvidia driver. We will call for a testing soon with the full instruction on what you will have to do. So keep your eyes open..

So long…

PS: follow me on Twitter here.

[CFT] xf86-video-ati 6.14.0

Howdy,

2 days ago was a new ati driver released. fluffy@ and me was using for
few weeks the git version without problems, but we’d like to make
sure this dosen’t broke anything for our ati users.
Here is a patch: http://people.freebsd.org/~miwi/ati-6140.diff
Changelog: http://lists.freedesktop.org/archives/xorg-announce/2011-February/001602.html

Please test and report back, if no problems I’d like to commit it next week.

thx
PS: this release fix some problems with HD54XX chips the bug with strg+ctrl+backspace; bug is gone for me.
PSS: Thx Dima for preparing the git tarball :P

User Thank You

Brandon Gooch, a system administrator at Southeastern Oklahoma State University, recently wrote the Foundation to express his gratitude towards FreeBSD developers in general and the recent wireless work in particular. The Foundation is always looking to collect appreciations and success stories, as well as pain points, that if addressed, could assist in FreeBSD adoption. When was the last time you pinged a developer on IRC or sent them a quick email to let them know how much you appreciate their work? It only takes a minute to let someone know that their hard work is being put to good use by others.

With Brandon's permission, his email text is re-posted here:

I'd like to thank Rui Paulo and Bernhard Schmidt, and Sam Leffler SO much for working so hard on the 802.11 stack and driver support. In my observations, wireless networking support (or lack of) from the OS seems to be one of the biggest deal-breakers when people I know try FreeBSD (from Linux or even Windows).

Driver support in general is a Good Thing and when one of my co-workers installs FreeBSD and his or her wireless card "just works" -- it looks really good for the project.

I'm sure there are still many issues left to resolve and still more features to implement. I believe that even better support is on the way. I also know that an OS can't be "all things to all people", but the solid code and great support from the developers and community make it a real pleasure to take part in the FreeBSD ecosystem.

I'm also very proud of the efforts of the FreeBSD Xorg devs (Robert Noland in particular) and the VirtualBox devs (Bernhard Froehlich and Co.). They have helped me implement several FreeBSD-based solutions at work due the the excellent features and performance of both Xorg and VirtualBox.

I look forward to opportunities to evangelize the FreeBSD project both in my professional and personal life. Thank you for making that task much easier.

Do not use synergy, use synergy+

For months, I’ve been plagued by intermittent mouse freezes on one of my boxes.

It started after a regular Xorg upgrade. According to various mailing lists, that particular upgrade caused similar problems to a lot of people, so I tried different suggested fixes. No luck.

A bit later, Xorg on FreeBSD was modified to fix the reported problems. But the upgrade did not fix my problem.

Eventually I came to a realization that it is likely that the problem is not with the mouse driver or with any other part of Xorg. Rather, it was a problem with synergy client interaction with the new xcb. I even found a problem report with a supposed fix to the problem. By the time I’ve found it, the fix was committed to the synergy port, and was subsequently rolled back because it lead to other problems. I tried the patch in the PR anyway. Still did not help me.

Not wanting to spend too much time on this, I was coping with the delays and only occasionally, when annoyed more than usual, was trying to find another fix. Unsuccessfully, I must add, until this morning, when I discovered synergy+, a maintenance fork of the original synergy. I was not aware that synergy+ is basically a drop-in replacement to synergy, the binaries having the same names as in the original. Better still, synergy+ client works just fine with the original synergy server. So I’ve decided to give it a shot, removed the synergy package, and installed the synergy+ port. Voila, the freezes are gone. I am a happy camper now.