5 The latest drm code from FreeBSD 9.x current has been successfully ported to DragonFly BSD, [patch](http://leaf.dragonflybsd.org/~davshao/r600fbsd.diff) and git branch **r600fbsd** git://leaf.dragonflybsd.org/~davshao/dragonfly.git, and tested with a Radeon HD 4550 on an x86_64 machine (Shuttle SG45H7). However it must be remembered that testing has only been done with this one graphics card and it is completely unknown whether say an Intel machine will lock up solid. Also nothing was done to port the extensive Via drivers FreeBSD has already ported.
7 ## Introduction or what the heck is being talked about
9 We are talking about modern graphics card drivers that have already or are in the process of being written for Linux. Fortunately for the BSDs the source code that is the basis of these drivers, part hosted in git repositories accessible from [freedesktop.org](http://cgit.freedesktop.org/), and even the part that is now residing in the Linux kernel, is mostly licensed under terms compatible with the [MIT X License](http://www.opensource.org/licenses/mit-license.php), and therefore can be directly ported to DragonFly.
11 When we refer to DRM, we are referring to the [Direct Render Manager](http://dri.freedesktop.org/wiki/DRM) that is a kernel module arbitrating requests for various graphics related services. Because of this acronym, the source code for DragonFly's DRM module can be found in directory **sys/dev/drm**, while the source code for Linux'd DRM module has been split into **include/drm** hosting common header files and **drivers/gpu/drm**. Furthermore the Linux files have had vendor specific code split off into their own separate directories, a change the BSDs should consider since having all files in one directory is becoming rather unwieldy.
13 ## Previous work makes the port possible
15 Simply take a diff of the FreeBSD and DragonFlyBSD versions of DRM and one can readily see that the hard work of translating the semantics of the locking for the Linux drivers has mostly been done, and better still can be done almost automatically. The FreeBSD port represents the limits of what can be ported having worked out exclusive access mechanisms, but not having completely worked out equivalents of other Linux APIs such as **idr**, small integer ID management.
17 ## What has been done and should be done
19 The software used for graphics whether the kernel or Mesa is surprisingly resilient. As long as it compiles it will try and find a way with dealing with other mismatched components by falling back on default behavior. Working on a fast x86_64 machine, it is easy to be lulled into a false sense that things are working properly unless one checks the logs.
23 Here the proper kernel module appears to be loaded. I wasted quite a bit of time earlier this week not realizing an error that led to the kernel module not being loaded at all that appeared from the messages to be a device non-existence problem.
25 drm0: <ATI Radeon HD 4550> on vgapci0
26 vgapci0: child drm0 requested pci_enable_busmaster
27 info: [drm] Initialized radeon 1.31.0 20080613
28 info: [drm] Setting GART location based on new memory map
29 info: [drm] Loading RV710 Microcode
30 info: [drm] Resetting GPU
31 info: [drm] writeback test succeeded in 1 usecs
33 ### **var/log/Xorg.0.log** output
35 Somewhere on one's system are the logs of the latest startup of the X server and the modules it finds. There can be an alternate place if one installs a second X.org, say at */opt/xtest*, in which case instead of **/var/log/Xorg.0.log** one will look in **/opt/xtest/var/log/Xorg.0.log**.
37 Here's a case of a failure where things are fine: I am composing this wiki from within Firefox 3.6.3 on a system where the proper module fails to load and yet where because of the machine's speed there is no discernible problem.
39 drmOpenDevice: node name is /dev/dri/card0
40 drmOpenDevice: open result is 10, (OK)
41 drmOpenByBusid: Searching for BusID pci:0000:01:00.0
42 drmOpenDevice: node name is /dev/dri/card0
43 drmOpenDevice: open result is 10, (OK)
44 drmOpenByBusid: drmOpenMinor returns 10
45 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
46 (EE) AIGLX error: dlopen of /usr/pkg/lib/dri/r600_dri.so failed (Cannot open "/usr/pkg/lib/dri/r600_dri.so")
47 (EE) AIGLX: reverting to software rendering
48 (II) AIGLX: Loaded and initialized /usr/pkg/lib/dri/swrast_dri.so
50 The Mesa 7.4.x series simply didn't *have* an r600_drv.so driver so of course it can't be found. Mesa happily falls back to using software rendering and nothing seems greatly wrong.
52 Now here is an example using latest Mesa and everything else from git where the driver is found:
54 [ 95.404] drmOpenDevice: node name is /dev/dri/card0
55 [ 95.405] drmOpenDevice: open result is 11, (OK)
56 [ 95.405] drmOpenByBusid: Searching for BusID pci:0000:01:00.0
57 [ 95.405] drmOpenDevice: node name is /dev/dri/card0
58 [ 95.405] drmOpenDevice: open result is 11, (OK)
59 [ 95.405] drmOpenByBusid: drmOpenMinor returns 11
60 [ 95.405] drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
61 [ 95.507] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
62 [ 95.507] (II) AIGLX: enabled GLX_SGI_make_current_read
63 [ 95.507] (II) AIGLX: enabled GLX_texture_from_pixmap with driver support
64 [ 95.507] (II) AIGLX: Loaded and initialized /opt/xtest/lib/dri/r600_dri.so
65 [ 95.507] (II) GLX: Initialized DRI GL provider for screen 0
66 [ 95.508] (II) RADEON(0): Setting screen physical size to 508 x 285
68 Ironically I knew I was on the right track porting the latest git versions of the X.org stack when I succeeded in locking up hard my machine. That meant a real hardware acceleration module was being loaded by that the previous kernel could not handle it, which was why the latest drm from FreeBSD had to be imported for Radeon r600.
70 ## Installing from pkgsrc
72 ### GNU m4 1.4.14 and bison 2.4.2
74 Patch both *devel/m4* and *devel/bison* using the patch idea from:
75 <http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=43098>
77 Unfortunately the problems are in the *work* directories so that one needs the knowledge from
78 <http://www.netbsd.org/docs/pkgsrc/components.html>
79 to even get the patches to be applied.
81 Install *pkgtools/pkgdiff*.
85 As of 2010-05-09, I find it necessary on x86_64 to use the following patch for
86 pkgsrc gstreamer0.10, an eventual dependency of the full xfce desktop:
88 --- pkgsrc/multimedia/gstreamer0.10/Makefile.orig 2010-03-29 16:04:23 -0700
89 +++ pkgsrc/multimedia/gstreamer0.10/Makefile 2010-03-29 16:09:04 -0700
92 .include "../../mk/bsd.prefs.mk"
94 +# __udivti3 error otherwise
95 +.if ${OPSYS} == "DragonFly" && ${MACHINE_ARCH} == "x86_64"
96 +MAKEFLAGS+= CCVER=gcc44
99 .if ${OPSYS} == "NetBSD"
100 # We must have a glib2 compiled with the RTLD_GLOBAL fix; if not, plugins
103 See for example the following bug report for more details:
104 <http://mail-index.netbsd.org/pkgsrc-bugs/2010/03/30/msg037304.html>
106 ## Building a separate version of X.org
108 We try something **ill-advised**, we build a separate version of X.org in another directory, say */opt/xbeta*,
109 on the same machine where we have installed the latext pkgsrc. We do this because we have no choice but to
110 use the graphics hardware on this machine, but the risk is that it is very easy to link the wrong libraries
113 ### expat and gettext
115 We start with installing into */opt/xbeta* [expat 2.0.1](http://sourceforge.net/projects/expat/)
116 and [gettext 0.17](http://www.gnu.org/software/gettext/).
118 ### Git repository for most of X.org
120 We use the following listing:
122 [freedesktop.org git repository browser](http://cgit.freedesktop.org/)
124 One can easily script getting, updating, and building the projects listed on that page.
126 ### Example of using ldd
130 libc.so.7 => /usr/lib/libc.so.7 (0x800640000)
131 $ ldd ./libXdmcp.so.6
133 libc.so.7 => /usr/lib/libc.so.7 (0x800640000)
135 ### libxcb problem with Python 2.6 cElementTree
137 Library *xcb/libxcb* unfortunately needs to be built early and there is a catch for
138 using pkgsrc Python 2.6. Unfortunately at the current time not all of
139 *cElementTree* appears to be functional; therefore, one needs a patch similar to
141 diff --git a/src/c_client.py b/src/c_client.py
142 index d86d05e..36a7039 100755
143 --- a/src/c_client.py
144 +++ b/src/c_client.py
146 #!/usr/bin/env python
147 -from xml.etree.cElementTree import *
148 +from xml.etree.ElementTree import *
149 from os.path import basename
153 As of May 20, 2010, the situation for libxcb seems to be more complicated. The latest *xcb/proto* needs
154 to be installed. If one does not wish to install on top of one's current Python modules,
157 export PYTHONPATH=${PREFIX}/lib/python2.6/site-packages
159 and apply a patch similar to below to change from using Python 2.6's *cElementTree* to *ElementTree*
161 diff --git a/xcbgen/matcher.py b/xcbgen/matcher.py
162 index e7958fa..16e8273 100644
163 --- a/xcbgen/matcher.py
164 +++ b/xcbgen/matcher.py
165 @@ -7,7 +7,7 @@ we do not create a new type object, we just record the existing one under a new
168 from os.path import join
169 -from xml.etree.cElementTree import parse
170 +from xml.etree.ElementTree import parse
174 diff --git a/xcbgen/state.py b/xcbgen/state.py
175 index 51efc94..e72dc3e 100644
176 --- a/xcbgen/state.py
177 +++ b/xcbgen/state.py
179 This module contains the namespace class and the singleton module class.
181 from os.path import dirname, basename
182 -from xml.etree.cElementTree import parse
183 +from xml.etree.ElementTree import parse
191 /usr/libexec/binutils217/elf/ld: .libs/extutil.o: relocation R_X86_64_PC32 against `xgeExtRegister' can not be used when making a shared object; recompile with -fPIC
192 /usr/libexec/binutils217/elf/ld: final link failed: Bad value
194 Use the following patch from <http://lists.x.org/archives/xorg-devel/2009-November/003724.html>
196 diff --git a/src/Xge.c b/src/Xge.c
197 index 7a583e5..2ea5d27 100644
200 @@ -294,7 +294,7 @@ _xgeEventToWire(Display* dpy, XEvent* re, xEvent* event)
202 * Extensions need to register callbacks for their events.
206 xgeExtRegister(Display* dpy, int offset, XExtensionHooks* callbacks)
212 We install [FreeType 2.3.12](http://www.freetype.org/). It appears that *GNUMAKE=gmake* is required.
213 Most of the X.org projects use *autogen.sh*, but here we use a standard call to *configure* somewhat
216 export ACLOCAL="aclocal -I ${PREFIX}/share/aclocal"
217 export PKG_CONFIG_PATH="${PREFIX}/lib/pkgconfig"
218 GNUMAKE=gmake ./configure --prefix=${PREFIX} CPPFLAGS="-I${PREFIX}/include -I${PREFIX}/X11/include" LDFLAGS="-L${PREFIX}/lib -Wl,-rpath -Wl,${PREFIX}/lib -L${PREFIX}/X11/lib -Wl,-rpath -Wl,${PREFIX}/lib/X11"
220 where *$PREFIX* is where we install X.org, say */opt/xbeta*,
221 the first two exports of *ACLOCAL* and *PKG_CONFIG_PATH* occur for most X.org projects,
222 *CPPFLAGS* and *LDFLAGS* ensure that the *$PREFIX* include directories and library paths
223 are used, and *-Wl,-rpath ...* is an incantation that ensures that previous built
224 *libtool* libraries can be used.
228 *autogen.sh* script seems to build easier with
234 As of 2010-05-09, known problem with GNU m4 pkgsrc on DragonFly
236 /usr/pkg/bin/gm4: m4_esyscmd subprocess failed: Operation not permitted
237 /usr/pkg/bin/gm4:configure.ac:8: cannot run command `${MAKE-make} -s -f bin/version.mk version | tr -d '\n'': Operation not permitted
238 configure.ac:8: error: Failed to get the Mesa version from `make -f bin/version.mk version`
240 For now just manually run command
241 $ make -f bin/version.mk version
243 and substitute it using a patch similar to
245 diff --git a/configure.ac b/configure.ac
246 index c40c842..224a858 100644
249 @@ -4,7 +4,7 @@ AC_PREREQ([2.59])
251 dnl Versioning - scrape the version from configs/default
252 m4_define([mesa_version],
253 - [m4_esyscmd([${MAKE-make} -s -f bin/version.mk version | tr -d '\n'])])
255 m4_ifval(mesa_version,,
256 [m4_fatal([Failed to get the Mesa version from `make -f bin/version.mk version`])])
260 If one uses the patches alluded to in the pkgsrc section, one can avoid the following build error:
263 bison: m4 subprocess failed: Operation not permitted
264 gmake[3]: *** [parser.c] Error 1