Bug 615 - [Matrox/MGA] 550 dual head does not initialize properly
Summary: [Matrox/MGA] 550 dual head does not initialize properly
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/mga (show other bugs)
Version: 7.1 (2006.05)
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Tilman Sauerbeck
QA Contact: Xorg Project Team
: 2492 (view as bug list)
Depends on:
Reported: 2004-05-13 10:26 UTC by Jeff Smith
Modified: 2007-09-30 05:29 UTC (History)
12 users (show)

See Also:
i915 platform:
i915 features:

xorg.conf (3.42 KB, text/plain)
2004-05-13 10:28 UTC, Jeff Smith
no flags Details
workaround for G550 dualhead mode (xorg (1.14 KB, patch)
2005-09-16 13:45 UTC, Alexander Smirnov
no flags Details | Splinter Review
My xorg.conf, containing two layouts: "SingleView" and "TwinView" (2.92 KB, text/plain)
2006-04-12 00:03 UTC, Manfred Knick
no flags Details

Description Jeff Smith 2004-05-13 10:26:57 UTC
When configuring dual head Matrox 550 video card, very strange things happen. 
Initially, it works fine.  When I reboot, the display on the second port (the
one with an adaptor) is dead (no signal), but it appears that the server has
configured the second port.  If I comment out the "Screen 1" line in the
"ServerLayout" section of the xorg.conf file and restart X, the second port
comes alive and displays as a cloned screen.  If I then uncomment the line and
restart the X server again, the second port correctly displays a second desktop
(or an extension of the first desktop if Xinerama is enabled).

It appears that the second port is not initialized if the "Screen 1" line
present, operating it in whatever mode it was configured previously.

There appears to be a similar bug posted to redhat at:


I'm running Fedora Core release 1.92

Comment 1 Jeff Smith 2004-05-13 10:28:04 UTC
Created attachment 284 [details]

xorg.conf config file
Comment 2 Denice 2004-10-07 14:56:44 UTC
I'm having this problem too - initially I have a working configuration.  After a
reboot one monitor is asleep and won't be easily revived.

Fedora core 2:
 $ rpm -q xorg-x11
 $ uname -r

From what I have observered this problem starts BEFORE graphics is enabled. 
I've run lots of xinerama configurations on matrox cards, and normally once
booting starts _both_ screens mirror the console output before runlevel 5.  
However in this case the 2nd monitor stays asleep.

One way to get the 2nd head going again is to run:
 # system-config-display --reconfig
and then cancel it.
This seems to send a probe that wakes up the 2nd monitor.  At that point running
startx will give you normal dual-head, xinerama functionality.
Comment 3 Manfred Knick 2004-10-17 03:58:04 UTC
I am using a G550 and two Eizo F980 / T960 in TvinView configuration under
current linux-2.6.8-gentoo-r10 on a dual-processor-machine.
After the current upgrade to x11-base/xorg-x11_6.8.0-r1, I had similar problems.
Just only replacing the mga_drv.o by the current binary one supplied by Matrox
solved all of them for me.

=============== Code: =====================
cd /usr/X11R6/lib/modules/drivers
mv mga_drv.o mga_drv.o_XORG   # BackUp - just to be safe;
cp -a
mv mga_drv.o mga_drv.o_Matrox
ln -s mga_drv.o_Matrox mga_drv.o   # this way, switching back is easy :-)
cll mga*
lrwxrwxrwx  1 root root      16 Oct 16 14:04 mga_drv.o -> mga_drv.o_MATROX
-rwxr-xr-x  1 root root 3605132 Oct 16 14:03 mga_drv.o_MATROX
-rwxr-xr-x  1 root root  200575 Oct 16 13:31 mga_drv.o_XORG
================= end Code ===============================

No need to modify /usr/X11R6/lib/modules/dri/mga_dri.so.
This way, after finding out how, it's done in less than a minute.

Replacing mga by the Matrox supplied source code also works (only takes longer).

RESUMMEE: It seems pretty obvious that the real cause is hidden in <...>/mga.

Left as a TODO :
- diff the Matrox source <...>/mgadrivers-3.0-src/4.3.0/drivers/src against

http://forums.gentoo.org/viewtopic.php?t=124779 (binary) and
http://forums.gentoo.org/viewtopic.php?t=160980 (from source).

Kind regards to all of you !
Comment 4 Dave Jones 2005-03-03 17:27:32 UTC
*** Bug 2492 has been marked as a duplicate of this bug. ***
Comment 5 Dave Jones 2005-03-03 17:29:32 UTC
for reasons unknown, this problem has actually got worse for me.
Now, uncommenting the Screen line and restarting X doesn't fire up the 2nd
monitor. It's totally dead no matter I do.  It also seems that only cloned mode
actually does something now. Worse still, the head I do get a display on doesn't
seem to have a mouse pointer.
Comment 6 Dave Jones 2005-03-03 17:31:53 UTC
Something odd in the logs...

(--) MGA(0): BIOS at 0xC1000000
(II) Truncating PCI BIOS Length to 36864
(--) MGA(0): Video BIOS info block at offset 0x07CC0
(WW) MGA(0): Video BIOS info block not detected!

I get that for both heads..
Comment 7 Michael Rommel 2005-03-27 11:33:21 UTC
Can confirm that using Fedora Core4-Test1 and X.Org 6.8.2 does still show the
same behaviour. This happens with a Matrox G400 PCI with one VGA and one DVI
port (but connected to an VGA monitor using an adaptor).

The exact same details as reported in
show up at my system.

MoBo is an VIA Epia M6000, BIOS has display priority set to PCI, the Unichrome
does not get initialized. Virtual console switching is broken too.

Using matrox' binary drivers for 6.8.1 (no 6.8.2 drivers were available) does
not work, X doesn't even come up.
Comment 8 Dave Airlie 2005-08-07 12:40:44 UTC
If someone has Xorg sources they could try removing the line in mga_driver.c
(6.8.2) or mga_bios.c in HEAD that does

        /* Get the output mode set by the BIOS */
        pMga->BiosOutputMode = BIOS[0x7ff1];

I'm not sure it is totally correct...
Comment 9 Alex Deucher 2005-08-17 07:51:45 UTC
Can you try xorg cvs HEAD?  Ian recently fixed up the PINS code in the mga
driver which may fix this.
Comment 10 Adrian von Bidder 2005-08-22 06:34:09 UTC
Alex, can you please identify the patch you are referring to?  If it is 
isolated enough so that I can apply it to Debian's latest Xorg in unstable, 
I'd be inclined to try it. 
Comment 11 Alex Deucher 2005-08-22 13:20:27 UTC
(In reply to comment #10)
> Alex, can you please identify the patch you are referring to?  If it is 
> isolated enough so that I can apply it to Debian's latest Xorg in unstable, 
> I'd be inclined to try it. 

see bug 3553
Comment 12 Alexander Smirnov 2005-09-15 13:01:31 UTC
I've tryed:

- 6.8.2 from FC development tree
- 6.8.2 from FC development tree + mga driver updated 
  from recent 6.9-RC0 tarball

with kernel 2.4.31 glibc2.1 and I have the same trouble with 
dualhead mode as described here - uninitialized second monitor.

My workaround is :

step1 :
  pMga->BiosOutputMode = 0x1; /*was BIOS[0x7ff1];*/

#define MGAuseI2C 1 /*was 0*/

  add needed symbols to i2cSymbols table to avoid Uresolved symbols warning

After these steps both dual- and singlehead modes work FINE with my G550!

Alex Smirnov.
Comment 13 Alexander Smirnov 2005-09-15 13:04:25 UTC
>#define MGAuseI2C 1 /*was 0*/

Sorry, I was mistaken: there has to be
#define MGAuseI2C 0 /*was 1*/

needed unresolved i2c symbols (+ 5-6 items) could be copied to mga_driver.c 
from other driver
Comment 14 Alex Deucher 2005-09-15 13:56:51 UTC
(In reply to comment #13)
> >step2:
> >#define MGAuseI2C 1 /*was 0*/
> Sorry, I was mistaken: there has to be
> #define MGAuseI2C 0 /*was 1*/
> P.S.
> needed unresolved i2c symbols (+ 5-6 items) could be copied to mga_driver.c 
> from other driver

Can you create a patch against cvs?  Also, Ian recently worked on the PiNS code,
perhaps he can shed some light on this (I've cc'ed him).
Comment 15 Alexander Smirnov 2005-09-16 13:45:08 UTC
Created attachment 3300 [details] [review]
workaround for G550 dualhead mode (xorg

workaround for G550 dualhead mode - patch for mga driver 
for xorg tarball, suitable for 6.8.2 too.
Comment 16 Erik Andren 2006-03-11 07:07:59 UTC
Has this patch been applied to HEAD?
Comment 17 Manfred Knick 2006-04-11 23:59:16 UTC
Re-flashing did not yield any difference to me.
Nor did the "newest" 1.5 BIOS (setup_258.exe, Sept. 15, 2005).

First, the patch worked absolutely fine for me.
After boot, there was only a signal on the HD15 connector, obviously being used
as the main display. No signal on the second connector (DVI -> HD15).
Interestingly enough, after the first "startx /usr/kde/3.5/bin/startkde -- 
-layout TwinView" and afterwards closing KDE, thus re-entering ASCII / VGA mode,
the signal is cloned to both screens.

Then, after a power-down - wait - reboot, same symptoms again ... really weird.

So I fell back to the clean unpatched  x11-drivers/xf86-video-mga- code

To me, the most reliable work-around still seems to be the following:
o) Connect your primary monitor to the HD-15/DVI-Adapter.
o) Connect your secondary monitor to the HD-15 Adapter.
o) Boot protocol will show up on the secondary screen. 
o) Log in.
I don't use any .xinitrc, but different shortcuts in my .alias - see below.
o) "startx /usr/bin/twm              --  -layout SingleView".
twm starts /exits much faster than kde.
o) Exit twm.
Now, you see your shell cloned on both screens.
o) "startx /usr/kde/3.5/bin/startkde --  -layout TwinView"
... - and, finally!, enjoy ...

Here the last snippet from my .alias:
alias   xtwms="startx /usr/bin/twm              --  -layout SingleView"
alias   xtwmt="startx /usr/bin/twm              --  -layout TwinView"
alias   xkdes="startx /usr/kde/3.5/bin/startkde --  -layout SingleView"
alias   xkdet="startx /usr/kde/3.5/bin/startkde --  -layout TwinView"

Hint: This topic entered into Matrox forum:
Comment 18 Manfred Knick 2006-04-12 00:03:17 UTC
Created attachment 5258 [details]
My xorg.conf, containing two layouts: "SingleView" and "TwinView"

My xorg.conf for G550 - Eizo F980 - Eizo T960i,
containing two alternative server layouts: "SingleView" and "TwinView"
Comment 19 Adrian von Bidder 2006-10-29 02:59:33 UTC
Recently, behaviour has slightly changed: now the 2nd head is initialized in 
my dualhead configuration as soon as I either quit X or switch to console 
mode.  So no need to fiddle with two configurations anymore, just log in on 
the first screen, then hit ctrl+alt+f1 and alt+f7 to switch to a text console 
and back again.

I first noticed this when upgrading Debian's xserver-xorg-video-mga package 
from 1: to 1:1.4.2.dfsg.1-1 (upstream versions to 
1.4.2, but I have no idea what patches the Debian package contains.  Also, I'm 
not sure which xorg version I should assign to this bug, apparently 7.1 is at 
1.4.1, couldn't find 1.4.2)

btw, this whole issue is also in the Debian bts at 

-- vbi
Comment 20 Ian Romanick 2006-10-30 16:04:58 UTC
(In reply to comment #19)
> I first noticed this when upgrading Debian's xserver-xorg-video-mga package 
> from 1: to 1:1.4.2.dfsg.1-1 (upstream versions to 
> 1.4.2, but I have no idea what patches the Debian package contains.  Also, I'm 
> not sure which xorg version I should assign to this bug, apparently 7.1 is at 
> 1.4.1, couldn't find 1.4.2)

Could you try it again with release 1.4.4?  That release was just made available
a couple days ago.

I finally have a G550 (it's PCI-e), so I should be able to start tinkering with
this later this week.
Comment 21 Tilman Sauerbeck 2007-02-01 10:19:54 UTC
What kind of hardware is this bug about?
a) g550 w/ one DVI connector, and one VGA connector
b) g550 w/ the LFH60 + dual-dvi cable?
c) g550 w/ the LFH60 + dual-vga cable?

I guess you're using the HAL module, since TMDS/DVI support is needed for all of these cards.

I think the card with the LFH60 connector has two TMDSs, and the dual-vga cable just translates the digital signal to an analog one. Does that make sense?

Anyway, I just got dual head working fine with a type a) card (without the HAL module). BiosOutputMode seems to be working correctly here. Inverting BiosOutputMode gives me a clone mode display, as expected.

The second crtc uses the video pll on g550 it seems, which doesn't like the values we feed it currently. For a 1280x1024@75 mode (DFP), the PMN values need to be 0x12/0x00/0x12. No idea what's going on there, didn't look at all the PLL code in detail.

EDID data retrieval seems to work alright as well, btw. I suspect this bug is mostly about errors in the HAL module?
Comment 22 Tilman Sauerbeck 2007-02-02 09:19:14 UTC
Figured out the VID_PLL problem: see bug #9854.
Comment 23 Daniel Stone 2007-02-27 01:23:30 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 24 Chris Howells 2007-08-01 04:44:08 UTC
Unfortunately this is still not working with the 1.4.4 drivers from Debian etch or 1.4.6 from Ubuntu Feisy Fawn. (I used debuild to compile the Ubuntu package on my etch system)

I wasn't sure if the patch mentioned in comment #22 was meant to fix it, but having applied it, it doesn't.

We are using AGP G550s which have both a VGA and DVI out, though we have analogue monitors connected to both, one using a DVI->VGA converter.
Comment 25 Tilman Sauerbeck 2007-08-02 03:49:02 UTC
Chris, please try the tip of the randr-1.2 branch of the mga git repository.

The released versions of xf86-video-mga do not support any DVI output (using an DVI->VGA adapter doesn't help!) without the mga_hal module.

In the randr-1.2 branch there's code that can control the DVI output though.


$ git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-mga
$ git branch randr-1.2 orig/randr-1.2
$ git checkout randr-1.2
$ ./autogen.sh
$ ./configure && make && make install

Note that this requires xorg-server 1.3.0 or later.

Once X is up, run
$ xrandr --output VGA --right-of DVI
to enable "real dual head" rather than clone mode.
Comment 26 Tilman Sauerbeck 2007-09-21 11:04:30 UTC
According to
the infamous "switched EDID data" bug is still alive in the randr-1.2 branch.
Comment 27 Tilman Sauerbeck 2007-09-21 15:49:08 UTC
I pushed a series of commits to randr-1.2 that fix the reported initialization problems.

The problematic case was: Use a DVI->VGA connector to attach a monitor via VGA.
This will cause the VBIOS to only enable the second output on boot rather than the first. We missed some bits that need to be enabled for the first output.

I still cannot reproduce the "switched EDID data" problem though. Can anybody who's seeing this test the latest randr-1.2 branch please?
Comment 28 Tilman Sauerbeck 2007-09-27 12:24:01 UTC
083d498b86fdc26cc915593ba6b17a00343881ea fixed the initialization problems, so I'm  resolving this bug.

See #4015 for the "swapped EDID data bug", which might still exist.
Comment 29 Tilman Sauerbeck 2007-09-30 05:29:10 UTC
*** Bug 2492 has been marked as a duplicate of this bug. ***

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.