|Summary:||[Matrox/MGA] 550 dual head does not initialize properly|
|Product:||xorg||Reporter:||Jeff Smith <jeff>|
|Component:||Driver/mga||Assignee:||Tilman Sauerbeck <tilman>|
|Status:||RESOLVED FIXED||QA Contact:||Xorg Project Team <xorg-team>|
|Priority:||high||CC:||alexdeucher, avbidder, bjorn, chris+bugs, davej, deatrich, drewelmore, idr, mhw-freedesktop, rommel, sja, tilman|
|i915 platform:||i915 features:|
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: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108073 I'm running Fedora Core release 1.92 Jeff
Comment 1 Jeff Smith 2004-05-13 10:28:04 UTC
Created attachment 284 [details] xorg.conf 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 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.
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 <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
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 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.
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];*/ 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.
Comment 13 Alexander Smirnov 2005-09-15 13:04:25 UTC
>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
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 126.96.36.1990) workaround for G550 dualhead mode - patch for mga driver for xorg 188.8.131.520 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-184.108.40.206 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
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:220.127.116.11.dfsg.1-2 to 1:1.4.2.dfsg.1-1 (upstream versions 18.104.22.168 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
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:22.214.171.124.dfsg.1-2 to 1:1.4.2.dfsg.1-1 (upstream versions 126.96.36.199 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 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. 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.
Comment 26 Tilman Sauerbeck 2007-09-21 11:04:30 UTC
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.
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.