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.

Yesterday I have committed a patch to fix mostly all problems under FreeBSD 10. I plan to make 10 exp-run after the 9.0 Release within 2 weeks to poke maintainers and upstream as to ensure that
for the 10.0 Release, everything is fixed and we can remove the current workaround. Appreciate all the help to get it to work.

Thx

I finally managed to get portscout back on a stable server. I have removed all mail addresses from the old portscout to cleanup all the unused mail addresses. If you are a maintainer and would like to get a mail notification, please drop me a mail using your maintainer mail address and I’ll add to the list. The RSS feature will be back very soon as well.Thanks to Martin Matuska (mm@) for hosting portscout now.

Note that portscout.org will be rerouted as soon as possible. As for now, please use http://portscout.cc.

- Martin

I’m looking for some fast Tinderbox build server (i386|amd64) for free,
if anyone have them please let me know …

- Martin

First of all, note that this is very experimental, so you really have to know what
you’re doing. We managed to get drm/dri with the newer xorg-server to work,
and we have removed the support for WITHOUT_NOUVEAU.

We have just updated the xorg-dev repo:

– libdrm -> 2.4.24
– libGL to 7.10.1
– libGLU to 7.10.1
– libGLUw to 7.10.1
– libglut to 7.10.1
– xproto to 7.0.17
– libXaw to 1.0.9
– libXt to 1.1.0
– libX11 to 1.4.1
– xorg-server to 1.9.4

After installing these, you will have to rebuild the following ports:

– your graphic driver
– keybord driver
– mouse/synaptics driver

Upon rebuilt, restart them.
So to get the xorg stuff you will need to:
run

svn co https://trillian.chruetertee.ch/svn/ports/branches/xorg-dev

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 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 -af

Please report any problems and issues to x11 (at) FreeBSD.org.

Again, please be aware that this is very experimental, and
I personally haven’t tested any 3D things yet, but we want
to share our work and start testing to get early feedback
for improvements. We plan to update Xorg fully to 7.6 after
we get some feedback for update part 1. It will be much easier
for us to figure out what the problems are with the updates
being separated in 3 parts. Please make sure you know what
you’re doing.

Thanks to Piter (gahr@) for helping me to get it compiled with our
base gcc version.

- Martin

PS: ECFT -> Experimental Call for Testing

Let me share a bit of my experience. I have (re)built a lot of
teams in the past, such as gecko@, kde@, python@, and I was
involved in the creation of FreeBSD vbox@ team. I have always
managed to get assistance from a lot of people, but recently more
and more people have started to complain about the slowness,
broken commits and requested for more Call for Testing. And that
is actually a big problem. I am the kind of person who like to
call for test, but I am also the kind of person who easily gets
disapointed when I’m not getting much feedbacks. The best example
here is ATI, Xorg and Xfce update. I did a call for testing because
Xorg and Driver updates is always a big issue because there are so
many different hardware involved with various configurations. From
the call for testing, we managed to get a total of 19 mails of
positive feedback and after 2 weeks I’ve committed the update.
What happened after that was I received a lot of complains for
not conducting much testing, yadda, yadda. Well I say it ain’t
my fault for not testing much, but it is also your fault for not
helping us. It is always easy to blame instead of helping. Ask
yourself why have you not helped us in testing properly and give
us feedbacks. Complaining is fine when it is done in the right
way, with the right tone.

While I’m talking about Xorg, the FreeBSD Xorg Team is currently
a one man show effort, supported by kwm@ and fluffy@. Xorg alone
is too big to get worked on. Plus you should not think that it is
affecting the ports only, but it affects the kernel as well, which
we are having the most problems at the moment. And of course I
would like to call for help on that as well. Based on my last call
for help, it is funny to see how many people wanted to offer some
help, but after knowing the amount of work involved, I have stopped
hearing from these guys. I understand that to update Xorg is always
a crappy job but I love doing it, because it is nice to get more and
more experience in understanding how things work, and it helps to
improve my skills a lot.

Lets a talk a bit about our FreeBSD KDE Team. KDE is nice, but it
really is a fat project. It needs a lot of love, and maintenance
time. Currently it’s a 4 people project, namely makc@, fluffy@ and
avilla@. While for support Raphael Kubo da Costa is handling it
actively. The thing is, KDE involves more than just KDE packages.
It includes Qt, PY-Qt, KOffice and Cmake as well. It is a big
project too and it would be nice to find more people to contribute
in the development.

And now lets talk about gecko@. gecko@ includes all Mozilla Project,
namely Firefox, Thunderbird and Seamonkey. It is currently maintained
by beat@ and decke@, and supported by flo@ and andreas. So again,
I’d like to see some fresh faces for this project as well. If you are willing
to help, do ping us via mail :p.

As for FreeBSD Gnome Team, well I can’t say much about gnome but
whenever I see the cvs commits in marcuscome tree, it seems like
most work for the upcoming gnome3 is done by kwm@, and supported
by marcus@, mezz@ and avl@. Gnome includes not only Gnome things
but it also include gtk and cairo, the one that always cause
problems in a major update. I think the team would love to have
some fresh blood in the team.

Okay, all of these need an understanding of programming and
scripting. If you think that you can’t do any of that, testing would
also help much. FreeBSD is one of the best documented open source
project, so that’s another area that could use some help too. Check
if FreeBSD.org is available in your language, or start helping to
improve the FreeBSD documents in your language. It would be very
helpful and the community will thank you for that. So if you would
like to offer some help, ping me in irc/jabber/mail

- Martin

I’d like to say thanks to Kris Moore, Josh Paetzel,
Dru Lavigne and of course the iXsystem for their
generous donation to build a test machine for KDE.

PS: This means not i jump back to the KDE Team
but I’m always willing to Help when i can.

I’d like to say many thanks to:

lwhsu@, wen@, bf@

Happy Updating.

Unfortunately there are some small bugs in the installation routine, when the filesytem is created for the first time without softupdates, you can easily change it in the rescue system, but the real problem is the swap. The swap size is only 300MB. Normally it is not big deal if you use a 64 bit system, but if you were to try to use your box as a package testing box like me, then you will run into a lot of problems, like the following:

swap_pager_getswapspace(4): failed
swap_pager_getswapspace(9): failed
swap_pager_getswapspace(3): failed
swap_pager_getswapspace(8): failed
swap_pager_getswapspace(2): failed
pid 95498 (httpd), uid 1003, was killed: out of swap space

I googled the error and found a nice workaround in beats@ blog. I
translated it in a short version, and hopefully the Webtropia team will try to fix that soon.

First, create a swap file and adjust the permission. The following example creates a large 1GB swap file:

# dd if=/dev/zero of=/usr/swapdatei bs=1024k count=1024
# chmod 0600 /usr/swapdatei

Now the swap file to the system is provided:

# mdconfig -a -t vnode -f /usr/swapdatei -u 0
# swapon /dev/md0

If you want the swap file to persist after reboot, add the following line to /etc/rc.conf:

swapfile=”/usr/swapdatei”

The system can be checked if it uses the additional swap file by using swapinfo (8):

# swapinfo
Device 1K-blocks Used Avail Capacity
/dev/ar0s1b 1048576 70204 978372 7%
/dev/md0 1048576 0 1048576 0%
Total 2097152 70204 2026948 3%

Thanks Beat for your awesome Blog . I hope this will help others who run into the same problem.