Planet FreeBSD

The FreeBSD GNOME team is proud to announce the release of GNOME 2.22.0 for FreeBSD. The official GNOME 2.22 release notes can be found at http://library.gnome.org/misc/release-notes/2.22/ . On the FreeBSD front, this release features an updated hal port with support for video4linux devices, DRM (Direct Rendering), and better support of removable media. Work is also underway to tie webkit more closely into GNOME. As part of the GNOME 2.22 upgrade, GStreamer received a rather large upgrade as well. Be sure to consult UPDATING on the proper steps to upgrade all of your GNOME ports.This release would not have been possible without the contributions and testing efforts of the following people: Pawel Worach, kan, edwin, Peter Ulrich Kruppa, J. W. Ballantine, Yasuda Keisuke, and Andriy Gapon.

Following on to Carl's update on our LCA talk, I've been trying to pull the 965 Render improvements out of the batchbuffer branch and onto master. Most of the changes in it are not actually dependent on batchbuffers or TTM. We can avoid reuploading programs without TTM. We can make bigger vertex buffers to reduce syncing without TTM. What the TTM branch (intel-batchbuffer) should be getting us is improved EXA pixmap migration performance, reduced memory fragmentation, more efficient buffer reuse, and possibly DRI2.

The current status of my work is at git://people.freedesktop.org/~anholt/xf86-video-intel on the 965-render-merge branch. It compiles, it runs, but the output is not quite what I hoped:



The code is mostly the same as what's on the branch, with just some changed buffer handling that should be all-or-nothing rendering correctness, not brokenness with colors. If I turn on xcompmgr, that desktop background goes thoroughly flourescent, and the windows partially translucent. Something very weird is going on, and I'm going to take a break and fix my 830/845 Render performance fix ("here test my patch, oh wait I didn't make it compile first") instead of bashing my head against this for now.

The last couple of weeks I've been very busy with school (and I expected this to be a quiet semester). However, I've found some of the last few bugs lurking around in csup:

• Deltas that had a 'hand-hacked' date would have deltatexts that would be misplaced in the rcsfile.
• When adding a new diff, a '..' would be converted to '.' twice, meaning it disappeared.

Now, there are only these issues left, but I'm not sure if I really want to fix this:

• Some RCS files have an extra space between desc and the deltas. CVSup fixes this by _counting_ the lines and then write them out when writing out the RCS file. I think this is silly, since it doesn't really matter according to the RCS standard.
• Some files appear to display garbage values, such as src/share/examples/kld/firmware/fwimage/firmware.img,v This disappears for some reasons in csup, but I'm not sure how to handle this. Comments are welcome.
• It has a quite high memory usage, and this might be due to some leaks that I've been unable to find. I'll do a much better audit of the code and run valgrind to investigate this further.
• Does not support md5 of RCS stream, so it can't detect errors yet.
• Statusfile file attributes might not be correct.
• Some RCS parts such as newphrases (man rcsfile) is not supported yet.
• Some hardcoded limits that may break it.
• Things done a silly way such as sorting and comparing, which I have plans to improve later.

So, finally, you can try out patches if you'd like: http://people.freebsd.org/~lulf/patches/csup/cvsmode

Currently, I'm including the tokenizer generated by flex, since the flex file itself can't be compiled with csup.