(no commit message)
authordavshao <davshao@web>
Fri, 9 Apr 2010 16:01:24 +0000 (09:01 -0700)
committerCharlie <root@leaf.dragonflybsd.org>
Fri, 9 Apr 2010 16:01:24 +0000 (09:01 -0700)
docs/developer/GEMdrmKMS/index.mdwn

index 3bb752e..efda0fb 100644 (file)
@@ -13,3 +13,40 @@ When we refer to DRM, we are referring to the [Direct Render Manager](http://dri
 ## Previous work makes the port possible
 
 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.
+
+## What has been done and should be done
+
+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.
+
+### **dmesg* output
+
+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.
+
+    drm0: <ATI Radeon HD 4550> on vgapci0
+    vgapci0: child drm0 requested pci_enable_busmaster
+    info: [drm] Initialized radeon 1.31.0 20080613
+    info: [drm] Setting GART location based on new memory map
+    info: [drm] Loading RV710 Microcode
+    info: [drm] Resetting GPU
+    info: [drm] writeback test succeeded in 1 usecs
+
+### **var/log/Xorg.0.log** output
+
+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/Xlog.0.log**.
+
+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.
+
+    drmOpenDevice: node name is /dev/dri/card0
+    drmOpenDevice: open result is 10, (OK)
+    drmOpenByBusid: Searching for BusID pci:0000:01:00.0
+    drmOpenDevice: node name is /dev/dri/card0
+    drmOpenDevice: open result is 10, (OK)
+    drmOpenByBusid: drmOpenMinor returns 10
+    drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
+    (EE) AIGLX error: dlopen of /usr/pkg/lib/dri/r600_dri.so failed (Cannot open "/usr/pkg/lib/dri/r600_dri.so")
+    (EE) AIGLX: reverting to software rendering
+    (II) AIGLX: Loaded and initialized /usr/pkg/lib/dri/swrast_dri.so
+
+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.
+
+