Contributed by tbert on from the la-mesa-es-loco dept.
I started the hackathon by updating libdrm to 2.4.51 which adds some interfaces required by the development versions of Mesa, and Mesa to 9.2.5 which corrects some minor bugs in the earlier 9.2.3 version we had.
I tried to look into building the development versions of Mesa again but this turned out to be painful for a few reasons. When Mesa switched build systems to autotools a few years back they broke builds on systems that don't have Linux/SVR4 style shared library versioning as they create symlinks to libraries by name instead of using libtool to infer a name. Various patches have been suggested to resolve this but none have been accepted. And now they build DRI3 support by default which requires udev.
From the xenocara point of view we can't accept a build dependency on python and various python modules and want to build r600 class radeon support without LLVM as LLVM is not present in either the src or xenocara trees. So for xenocara we have our own set of Makefiles to build Mesa with the files pregenerated from the Khronos XML API definitions by the python scripts.
And to get anything beyond basic modesetting on the newer GCN/Southern Islands radeons we must link to LLVM, support non X11 EGL contexts, which requires the 'gbm' memory management in Mesa, which requires udev or some new ioctls. This is because there is no traditional xorg driver support written for newer radeons, only an OpenGL based 2d driver that uses glamor (http://www.freedesktop.org/wiki/Software/Glamor/). I started work on getting gbm running a while back but never managed to get it working.
So after being reminded of how painful Mesa was I went back to trying to update our drm code in the kernel from Linux 3.8 based code to Linux 3.10. Linux 3.10 being a 'longterm' version which should make bringing in bug fixes easier and add a bit more hardware support. I got most of the way through the ttm and radeon code and decided to suspend work on that and come back to it later rather than face the Intel code, which has an incredibly high rate of churn.
Then I started looking for problems in the src tree by running clang, the clang static analyser and cppcheck.
cppcheck found a lot of format string problems in the kernel (we compile with -Wno-format for various reasons), and some memory and fd leaks mostly contained to error paths.
One of the leaks fixed was in getgrouplist() where it would leak memory every time a key was found in /etc/netid in YP setups. Thanks to Ingo for constructing a test setup to verify the problem and the fix.
At some point Mark Kettenis and I agreed that we should try to pick up the remaining drm fixes from the Linux 3.8 tree maintained for Ubuntu (3.8 no longer being maintained on kernel.org) so I started committing these changes over the remaining parts of the hackaton, though there is still some work to do there.
(Comments are closed)
By Bonaventure Soriaux (31.193.133.168) on