Page 1 of 1

Easy-To-Understand Explanation of Driver Requirements

PostPosted: Mon Feb 05, 2007 4:31 pm
by IntuitiveNipple
I'd like to suggest the creation of a simple, top-down description of Matrox hardware acceleration support. I'm a hacker myself but I'm still getting endlessly confused by the fragments of information found in searches.

There seem to be several 'layers' of drivers, starting with the kernel framebuffer, kernel drivers to support DRI, to support YUV in hardware, Then for X there's HAL, there's Matrox drivers, Xfree, Xorg and DirectFB drivers!

Can we put together something that is easy to understand? I'll give you an idea of what I'd like to see by making a start on what I am learning, for the G450 with dual-head, and let those with more knowledge of Matrox drivers add their corrections and additional knowledge and experience.

I will re-edit this post until it is complete and correct.

Matrox G450 AGP dual-head Hardware Acceleration

This information is based on kernel 2.6.17-10 with Ubuntu Edgy 6.10 (a Debian flavour). It may be accurate for many other flavours and versions too, but please consider version differences when investigating issues.


These are the Matrox-specific components that we have to deal with.
  • Kernel Matrox Direct Rendering Manager (DRM) mga.ko
  • Kernel console framebuffer matroxfb_*.ko
  • Kernel TV-Out support i2c-matroxfb.ko matroxfb_crtc2.ko
  • Kernel VGA Display Data Channel (DDC) matrox_w1.ko
  • Kernel YUV Video Playback mga_vid.ko
  • Kernel DirectFB & XDirectFB driver for single-solution 2D/3D hardware acceleration
  • X xorg Direct Rendering Infrastructure (DRI) driver
  • X xorg (open source) MGA driver
  • X Matrox MGA driver
  • X Matrox Hardware Abstraction Layer (HAL) driver

What the bits do

This explanation is borrowed from the ATI-focused Guide to debugging DRI installation

3D Acceleration: Components

Accelerated Graphics Port, Graphics Address Remapping Table (AGPGART)
part of Linux kernel

agpgart is needed to make use of the AGP connector. It is motherboard specific. To enable turn on agpgart support for the motherboard in Linux kernel.

Reported during boot, in /var/log/dmesg:
Code: Select all
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected AMD 760MP chipset
agpgart: AGP aperture is 256M @ 0xe0000000

See Wikipedia AGPGART

Memory Type Range Registers (MTRR)
part of Linux kernel

Tells the CPU that certain memory address ranges (namely the framebuffer and register apertures of your video card) need to be treated differently from usual RAM. This dramatically accelerates 2D performance and is recommended for hardware 3D.

See Wikipedia MTRR

Direct Rendering Manager (DRM)
part of kernel

DRM stands for Direct Rendering Manager. It is a kernel module responsible for mediating access to video hardware.

Can usually be found as /usr/lib/

See Wikipedia DRM

Direct Rendering Infrastructure (DRI)
part of Mesa OpenGL

DRI is an interface used in the X Window System to securely allow user applications to access the video hardware without requiring data to be passed (slowly) through the X server. Its primary application is to provide hardware acceleration of the Mesa implementation of OpenGL.

DRI modules can be found in /usr/lib/dri/

See Wikipedia DRI

Mesa 3D OpenGL
Open-source OpenGL implementation

Provides a generic OpenGL implementation for rendering three-dimensional graphics on multiple platforms.

OpenGL libraries can be found at /usr/lib/libGL*

See Wikipedia Mesa 3D

part of X

XFree86 is the Xserver binary that comes with distributions of XFree / Xorg. Unless you have a static server (very unlikely) this binary will want to load various modules which usually reside in /usr/lib/xorg/lib/modules/

Video driver module(s)
part of X

The module in the X Server that provides 2D support and infrastructure for the client side part of the DRI.

For Matrox cards these are and The optional Hardware Abstraction Layer (HAL) module provides support for dual-head, TV, and DVI flat-panels.

These drivers usually reside in /usr/lib/xorg/lib/modules/drivers/

DRI module
part of X

Client 3D module (/usr/lib/xorg/modules/extensions/ which are loaded by programs linked with libGL.

Its primary application is to provide hardware acceleration via the Mesa implementation of OpenGL.

GLX module
part of X

Provides Graphics Language eXtension support. Can usually be found as /usr/lib/xorg/lib/modules/extensions/

GLcore module
part of X

Provides core Graphic Language support. Can usually be found as /usr/lib/xorg/lib/modules/extensions/

GL/GLU library
part of OpenGL

These are the libraries used by user applications. They are usually named and Beware ! - they are often distributed standalone with software-only GL support.

Your application that uses GL. unless it uses the correct GL library it will not try to do hardware accelerated 3D.

Boot Time and Kernel

Direct Rendering Manager (DRM)
This is responsible for configuring the AGP interface amongst other things.

Frame Buffer

Linux Kernel optionally loads a framebuffer driver. This can be compiled into the kernel, or loaded as a module. When using the Matrox framebuffer driver (matroxfb_*.ko files) the video modes are selected on the kernel command-line using the prefix video=matroxfb:

Here's an extract from a typical boot-log (/var/log/dmesg):
Code: Select all
Kernel command line: root=/dev/hda7 ro debug video=matroxfb:vesa:0x11B,depth:32
matroxfb: Matrox G450 detected
PInS memtype = 5
matroxfb: MTRR's turned on
matroxfb: 1280x1024x32bpp (virtual: 1280x3276)
matroxfb: framebuffer at 0xDC000000, mapped to 0xf8880000, size 33554432
Console: switching to colour frame buffer device 160x64
fb0: MATROX frame buffer device
matroxfb_crtc2: secondary head of fb0 was registered as fb1

If you have the Linux kernel source installed, the range of options are found in the documentation in the file /usr/src/<linux-kernel-version>/Documentation/fb/matroxfb.txt

How to use it?

Switching modes is done using the video=matroxfb:vesa:... boot parameter or using `fbset' program.

If you want, for example, enable a resolution of 1280x1024x24bpp you should pass to the kernel this command line: "video=matroxfb:vesa:0x1BB".

You should compile in both vgacon (to boot if you remove you Matrox from
box) and matroxfb (for graphics mode). You should not compile-in vesafb
unless you have primary display on non-Matrox VBE2.0 device (see
Documentation/fb/vesafb.txt for details).

Code: Select all
Currently supported video modes are (through vesa:... interface, PowerMac has [as addon] compatibility code):

[Graphic modes]

bpp | 640x400  640x480  768x576  800x600  960x720
  4 |            0x12             0x102           
  8 |  0x100    0x101    0x180    0x103    0x188   
15 |           0x110    0x181    0x113    0x189   
16 |           0x111    0x182    0x114    0x18A   
24 |           0x1B2    0x184    0x1B5    0x18C   
32 |           0x112    0x183    0x115    0x18B   

[Graphic modes (continued)]

bpp | 1024x768 1152x864 1280x1024 1408x1056 1600x1200
  4 |   0x104             0x106
  8 |   0x105    0x190    0x107     0x198     0x11C
15 |   0x116    0x191    0x119     0x199     0x11D
16 |   0x117    0x192    0x11A     0x19A     0x11E
24 |   0x1B8    0x194    0x1BB     0x19C     0x1BF
32 |   0x118    0x193    0x11B     0x19B

[Text modes]

text | 640x400  640x480  1056x344  1056x400  1056x480
8x8 |  0x1C0    0x108     0x10A     0x10B     0x10C
8x16 | 2, 3, 7                       0x109

You can enter these number either hexadecimal (leading `0x') or decimal (0x100 = 256). You can also use value + 512 to achieve compatibility with your old number passed to vesafb.

Non-listed number can be achieved by more complicated command-line, for example 1600x1200x32bpp can be specified by `video=matroxfb:vesa:0x11C,depth:32'.


XF{68,86}_FBDev should work just fine, but it is non-accelerated. On non-intel architectures there are some glitches for 24bpp video modes. 8, 16 and 32bpp works fine.

Running another (accelerated) X-Server like XF86_SVGA works too. But at least) XFree servers have big troubles in multi-head configurations (even on first head, not even talking about second).

Running XFree86 4.x accelerated mga driver is possible, but you must not enable DRI - if you do, resolution and color depth of your X desktop must match resolution and color depths of your virtual consoles, otherwise X will corrupt accelerator settings.

When complied in, matrox framebuffer options are selected using the kernel configuration utility menuconfig:
Code: Select all
# make menuconfig

Information on what to select is at Matrox G400 Dual Head Kernel Settings

To set the video mode at boot-time, the following line is added to the boot-loader configuration (1280x1024, 32 bits-per-pixel):


Report of loaded modules related to Matrox when matroxfb has been built-in to kernel:
Code: Select all
# lsmod | grep '.*mga.*\|.*matrox.*'
mga                    63744  2
drm                    74260  3 mga
matrox_w1               5248  0
wire                   27036  1 matrox_w1

YUV video interface for accelerated video playback

This is an interface to the Matrox hardware Back End Scaler (BES). It accelerates the playback of video by using the graphics card to decode the YUV-encoded video signal.

It was originally (1999) developed for MPlayer but the MPlayer version does not support kernel 2.6.x. It can be used by programs such as MPlayer through an optional switch to use hardware rendering of YUV signals.

Source code for kernel 2.6.x is available so the qualification that it will only work with kernel 2.4.x is no longer valid. The latest is available from

The latest Ubuntu (Debian) source packages are available from

This is a combination of a video output driver and a Linux kernel module for the Matrox G200/G400/G450/G550 BES (Back-End Scaler). It has hardware VSYNC support with triple buffering. It works on both framebuffer console and under X...

MPlayer documentation on Matrox framebuffer (mga_vid)

Another user's experience with kernel 2.6.17 and Ubuntu:
The only issue I found is that the 1.55-1.2 module creates its device as /dev/mga_vid0 rather than the /dev/mga_vid that mga_vid_test and mplayer expect.

I added this line to /etc/modutils/mga-vid-common to fix that issue:
post-install mga_vid ln --force -s /dev/mga_vid0 /dev/mga_vid

One last thing is that I found the output of mga_vid_test garbled when I ran it at a text-mode console but when I used a framebuffer console (e.g. vga=0x305 in the kernel boot parameter line), the Matrox output was correct. It also worked with mplayer as expected (which was the desired end-result).

mga-vid-source fails to compile


This solution is intended to provide a single implementation of all the 2D/3D acceleration functions, making use of the hardware support where available. Matrox are supposed to be some of the best-supported cards.

Matrox G-Series/Millennium/Mystique

Combined with XDirectFB, an X11 server, it provides a single solution for hardware acceleration for consoles and X-windows without the mess of drivers we currently have to deal with.

I'm currently investigating this solution and will report back on it

DirectFB is a thin library that provides hardware graphics acceleration, input device handling and abstraction, integrated windowing system with support for translucent windows and multiple display layers, not only on top of the Linux Framebuffer Device. It is a complete hardware abstraction layer with software fallbacks for every graphics operation that is not supported by the underlying hardware.


X Windowing System

This is, to me, the most confused area. There appear to be many different versions, from the original Matrox binary+source, to the modified source provided here by 'tux', to several open-source versions from xorg, xf86, and DirectFB!

X11 3D support

X11-DRM is an enhancement to Xorg that adds 3D acceleration for cards by adding the kernel module necessary for direct rendering.

This is provided by the DRI and GLX modules in X. Indication in /etc/X11/xorg.conf:
Code: Select all
Section "Module"
  Load "dri"
  Load "glx"
Section "Device"
  Driver "mga"
Section "dri"
  Mode 0666

Matrox with hardware acceleration

The package provided and supported here so well by 'tux' for the 2.6.x kernels. For dual-heads use it in MergedFB configuration. This contains what Linux purists call a tainted module (because the source-code isn't released by Matrox) - the Hardware Abstraction Layer (HAL) /usr/lib/xorg/modules/drivers/

As is proved by this site and the experience of so many of us, not providing open-sourced drivers means Matrox customers get left behind when Matrox decides it no longer supports the hardware.

It is loaded by the main X driver you see referred to in xorg.conf and /var/log/Xorg.0.log.
Code: Select all
(II) Loading /usr/lib/xorg/modules/drivers/
(II) Module mga_hal: vendor="Matrox Graphics Inc. - x86_32 - Release v4.4.0"
   compiled for 7.0.0, module version = 1.0.0
   ABI class: X.Org Video Driver, version 0.8
(WW) module ABI major version (0) doesn't match the server's version (1)
(==) MGA(0): Matrox HAL module used

To ensure the ABI version mismatch is over-ridden so it will work with Xorg 7.1.1 the option ignoreABI is used in xorg.conf or on the command line:
Code: Select all
Section "ServerFlags"
Option "IgnoreABI" "True"

In order for this accelerated AGP4x and MGA HAL to work, the ServerFlag ignoreABI must be added. If it isn't read and honoured in this file, add it to /etc/gdm.conf like this (find this section and add the -ignoreABI flag to the command):
command=/usr/X11R6/bin/X -ignoreABI -br -audit 0

Xorg driver with software acceleration

This is the xorg mga driver. The options for configuring xorg.conf are in the man-pages which are also on the web site:
man-pages: mga - Matrox video driver

Xorg driver with hardware acceleration

This is the xorg mga driver combined with the binary HAL driver

Support for the HAL has recently (January 2007) been broken in the source code (v1.4.6.1) and is to be removed completed (see Xorg bug #9878).
mga is an Xorg driver for Matrox video cards. The driver is fully accelerated, and provides support for the following framebuffer depths: 8, 15, 16, 24, and an 8+24 overlay mode. All visual types are supported for depth 8, and both TrueColor and DirectColor visuals are supported for the other depths except 8+24 mode which supports PseudoColor, GrayScale and TrueColor. Multi-card configurations are supported. XVideo is supported on G200 and newer systems, with either TexturedVideo or video overlay. The second head of dual-head cards is supported for the G450 and G550. Support for the second head on G400 cards requires a binary-only "mga_hal" module that is available from Matrox

Xorg using DirectFB
XDirectFB is a rootless X Server using DirectFB windows for X11 toplevel windows. This way you can adjust the opacity of every application with your mouse wheel (while holding Meta down over a window).


Testing & Measuring Performance

In X, from an xterm, you can run glxgears to measure the frame-rate:
Code: Select all
# glxinfo
name of display: :0.0
libGL warning: 3D driver claims to not support visual 0x4b
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:

# sudo mga_vid_test
Testing MGA G400 Backend Scaler with 32 MB of RAM
mga_vid_base = 0xb7d87000
(1) There should be a green square, offset by 10 pixels from
    the upper left corner displayed
(2) There should be a cool mosaic like pattern now.
(3) There should be a color blend with black, red, purple, blue
    corners (starting top left going CW)

# glxgears -printfps
libGL warning: 3D driver claims to not support visual 0x4b
1558 frames in 5.0 seconds = 311.592 FPS
1566 frames in 5.0 seconds = 313.121 FPS
1558 frames in 5.0 seconds = 311.585 FPS
1566 frames in 5.0 seconds = 313.153 FPS
1576 frames in 5.0 seconds = 315.045 FPS

These results are with the default GLXgears window visible on screen 0 with 24 bits-per-pixel Using 16 bits-per-pixel the scores increase to around 500 FPS.
What are the expected GLXgears results for Matrox adapters?

The Direct Rendering Infrastructure (DRI)Project Wiki
The DRI Project Wiki Matrox page
Direct Rendering Module (DRM) trouble-shooting
Direct-FB Wiki Matrox G400 Dual Head
[url=]Matrox Marvel G200/G400/G450eTV/Rainbow Runner G-series
support in Linux via Video4Linux I and II[/url]
MPlayer documentation on Matrox framebuffer (mga_vid)
Ubuntu Edgy Matrox G400 - G450 TV out HOWTO

PostPosted: Fri Feb 09, 2007 1:37 pm

I'm very amazed about this piece of information and will have to dig through
this this weekend (unfortunately my son is currently ill and so time is limited),
_BUT_ if you don't mind, I'd like to add some things, resp. do some corrections
to this text and move it to the HOWTO section or anything that is appropriate
for this topic.

Awaiting your reply...

PostPosted: Fri Feb 09, 2007 2:51 pm
by IntuitiveNipple
It was my intention that the accumulated knowledge of the hackers be shared rather than expecting basic users to try and understand the various issues.

Can I suggest, if you move it to the HowTo section, that we continue contributing experience and knowledge into the thread and then, at some point in the future, clean it all up to create a single document that doesn't confuse end-users?

PostPosted: Sat Feb 10, 2007 12:56 am
Can I suggest, if you move it to the HowTo section, that we continue
contributing experience and knowledge into the thread and then, at some point
in the future, clean it all up to create a single document that doesn't confuse

Great idea, but I'd suggest to use some kind of versioning tool or patch
management for this document, so that we are able to see the changes the
other one made.

Using vim and diff would be enough for me, don't know how you think about

PostPosted: Sat Feb 10, 2007 3:08 pm
by IntuitiveNipple
My thinking was more ad-hoc, at least for now:

Accumulate the material in this thread, and then edit the initial post to include corrections and new information as it becomes available.

I'm starting to test the DirectFB/XDirectFB approach right now - that will add a chunk of new information.

I think we should also publish the expected performance metrics of each approach to give users an idea of what to expect. Although not perfect, using glxgears is probably easiest and simplest to understand for most end-users in that it will show them the relative performance of the same test on different drivers.

I'm very disappointed so far in the performance of all the Linux drivers.

Google Earth, one of my primary must-haves (for development work), is practically unusable on Linux but had no problems whatsoever on Windows.

This is what is driving me to understand precisely what is going on with the Linux drivers, so hopefully I can do some hacking and improve matters.

PostPosted: Wed Feb 14, 2007 4:02 pm
I'm starting to test the DirectFB/XDirectFB approach right now - that will add a
chunk of new information.


I'm very disappointed so far in the performance of all the Linux drivers.

If you are looking for drivers with performance, have a look at [Xig].

PostPosted: Wed Feb 14, 2007 4:11 pm
by IntuitiveNipple
Yes, I've already got the XiG X server. The problem is it doesn't fit well with my existing Ubuntu configuration, and if I wanted to go the proprietary route I'd stick with Windows.

As well as Windows being far cheaper - the entire Windows O.S. costs less than just the XiG X Server I'd need ($200) - the Windows video driver performs better than the XiG X server, too!

PostPosted: Wed Feb 14, 2007 4:36 pm
Yes, I've already got the XiG X server.

Alright. I'm currently evaluating the APVe driver from then, but at the moment
I'm stuck at dualhead setup. Triplehead doesn't work for me now...

if I wanted to go the proprietary route I'd stick with Windows.

Good point.

PostPosted: Mon Jul 09, 2007 7:16 am
by kimmie

I'd like to thank you for posting such a great resource. I recently went through the process of migrating my desktop to linux. As I expected, a lot of the time was spent getting X going dual head with the G450. The info in your post allowed to understand and evaluate the alternatives, and to know when to stop trying to improve things. You saved me lots and lots of time. Thanks.

Looks like your board is the prime resource older matrox card on linux. Many thanks to you also.


I notice you started discussing the future of this thread, ie. moving, collating etc. It seems that stalled. I humbly suggest moving this thread to the G-Series forum and making it sticky; it really doesn't seem to have gotten the attention it deserves, and that might at least provide some stimulation.

a little about my experience:

I'm using xorg 7.2 on gentoo. I couldn't get to work with this driver, even with the "IgnoreABI" work-around, it would always segfault. I tried installing the drivers from this board so I could get MergedFB working, and they did work, but only at 1024x768-1024x768 resolution. I have old 19" CRTs, and 1280x960 is the minimum acceptable for me. I even tried 16bpp, but still no dice, the log messages complained that the pixel clock was too high on the second head, even though the mode should have been well in range.

For the moment, I've settled for the stock xorg driver, using Xinerama. But xorg bug #9878 gives me some hope: although it states that mga_hal_drv.o support (and therefore MergedFB support) is scheduled to be removed from the xorg driver, it also says that there are plans to put MergedFB support into the standard driver. My plan is to wait a while and see what happens on that one.

I'm also disappointed as to the driver support for hardware OpenGL. I was hoping that it would be better under linux than windows, but in fact, it sucks either way. Under windows Google Earth was ok... until I tried to add buildings, then it just went haywire. Rosetta@Home occasionally locked the machine (hard reset required) if I tried showing graphics, as did a few other apps. In the end under windows I settled for a WHQL driver without 3D support; ie. I gave up. That way, at least my machine didn't lock up. Under linux, I haven't had lockups at least, but the only 3D app I tried (Einstein@home, which is pretty much a wireframe only) renders the 3D overlay in the wrong place when I'm using dual head, it doesn't move with the window. So once again, I gave up. To commemorate the occasion, I went and disabled DRI on the first head in my xorg.conf. Sigh. Perhaps the card itself just isn't up to basic 3D.

I'm curious as to how you went with DirectFB, but I'm too lazy to try it myself right now, I've had enough of fiddling with my X setup.

What else? I got the mga_vid driver going (mga_vid-2.6.18-2006-09-27). It failed to build under my 2.6.20 kernel until I patched mga_vid.c to #include <linux/autoconf.h> instead of <linux/config.h>. After doing that, and following the REAME instructions about udev, it was fine. But using it sometimes causes glitches on the second head, and the performance doesn't really seem much better than xv, so I ditched it. Video seems to work well with xv, except for a few funny horizontal lines that seem to depend on where the video window is placed on the screen, and how big it is. Sometimes, they don't appear at all. Weird, but not really a problem, I just move the window a bit and they go away.

All in all, I agree the G450 / dual-head combination is a bit of a disappointment as far as hardware acceleration goes.

I wish I had more to contribute, but that's it. Thanks again! :)

PostPosted: Mon Jul 09, 2007 10:21 pm
I notice you started discussing the future of this thread, ie. moving, collating
etc. It seems that stalled.

That's right, yes. IntuitiveNipple hasn't logged in a while to my little forum
and I don't have enough time to write things up appropriately.
Maybe you have? ;)

PostPosted: Tue Jul 10, 2007 2:45 am
by kimmie
Maybe I do have some time. But I'm not sure what you mean by "appropriately"? What sort of changes are you thinking of?

PostPosted: Tue Jul 10, 2007 5:18 pm
Check if all the information above is still up-to-date, group similar objects
together, etc.

I'm not that much into the G-series cards, so I'm not the right one for this

PostPosted: Thu Jul 12, 2007 3:21 pm
by kimmie
Ok, I've read the discussion you guys had in more detail now... seems you were thinking of turning this thread into an end-user comprehensive howto of some sort? And you think that it's inappropriate as it stands now?

I guess I agree that it's not an end-user howto. But I don't think I want to bother trying to turn it into one either. Way too much work, and the info is available elsewhere anyway. The main point for me wasn't the "how-to-ness", it was just the summary of all the parts and how they fit together, and the references. If I was going to edit that up, I'd probably remove some detail :)

Ah well. Perhaps it'll just have to stay just like it is.

PostPosted: Fri Jul 13, 2007 10:21 am
seems you were thinking of turning this thread into an end-user
comprehensive howto of some sort?

That's right, yes. The problem with this is, that I'm not that familiar with
all the stuff covered in this article and therefore I can't support it out of the
box as it is currently.

Ah well. Perhaps it'll just have to stay just like it is.

You're right, I think I'll make up a sticky post in the G-Series forum with this


PostPosted: Tue Mar 25, 2008 1:05 am
by jonib
IntuitiveNipple wrote:I'm starting to test the DirectFB/XDirectFB approach right now - that will add a chunk of new information.

Hi IntuitiveNipple.
I have been trying to get clonemode to work including video output to my TV with mga 4.4.3 drivers on my Matrox G400DH without success.
Next I want to look into DirectFB and was wondering how your testing went? as most information I have found is several years old and seems outdated.