Bug 615

Created attachment 284 [details]
xorg.conf

xorg.conf config file

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
 xorg-x11-6.7.0-9
 $ uname -r
 2.6.8-1.521smp

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.

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
<where-you-unpacked-matrox-binary-download>/mgadrivers-3.0/xfree86/4.3.0/drivers/mga_drv.o
.
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
bash-2.05b#
================= 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.

ALTERNATIVE:
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
<Xorg>/xc/programs/Xserver/hw/xfree86/drivers/mga

REFERENCES:
http://forums.gentoo.org/viewtopic.php?t=124779 (binary) and
http://forums.gentoo.org/viewtopic.php?t=160980 (from source).
http://forum.matrox.com/mga/viewforum.php?f=51
http://forums.gentoo.org/viewtopic.php?t=1656594
http://bugs.gentoo.org/show_bug.cgi?id=22269.

Kind regards to all of you !
Manfred

*** Bug 2492 has been marked as a duplicate of this bug. ***

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.

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..

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
  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108073
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.

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...

Can you try xorg cvs HEAD?  Ian recently fixed up the PINS code in the mga
driver which may fix this.

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. 

(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

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];*/

step2:
#define MGAuseI2C 1 /*was 0*/

step3:
  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.

>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

(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).

Created attachment 3300 [details] [review]
workaround for G550 dualhead mode (xorg 6.8.99.900)

workaround for G550 dualhead mode - patch for mga driver 
for xorg 6.8.99.900 tarball, suitable for 6.8.2 too.

Has this patch been applied to HEAD?

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-1.2.1.3 code
again.

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:
http://forum.matrox.com/mga/viewtopic.php?p=97295#97295

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"

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:1.2.1.3.dfsg.1-2 to 1:1.4.2.dfsg.1-1 (upstream versions 1.2.1.3 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 
<http://bugs.debian.org/324500>

greetings
-- vbi

(In reply to comment #19)
> I first noticed this when upgrading Debian's xserver-xorg-video-mga package 
> from 1:1.2.1.3.dfsg.1-2 to 1:1.4.2.dfsg.1-1 (upstream versions 1.2.1.3 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.

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?

Figured out the VID_PLL problem: see bug #9854.

Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.

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.

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.

So:

$ 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.

According to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=324500
the infamous "switched EDID data" bug is still alive in the randr-1.2 branch.

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?

083d498b86fdc26cc915593ba6b17a00343881ea fixed the initialization problems, so I'm  resolving this bug.

See #4015 for the "swapped EDID data bug", which might still exist.

*** Bug 2492 has been marked as a duplicate of this bug. ***