This bug has something common with bug #194515 ... since, the problem is a broken feature, without explicit message about it.
It is radically different since in present case, X starts, and works for some heads.
I consider this as a MAJOR bug because:
- a video output is missing
- there is no explanation for this failure
Problem: when I uncomment line for Screen 4, screen 4 does not light.
More details coming with attached files.
*** *** ***
root@moon_gen_2:/var/log# diff Xorg.0.log_missing_4th_bug4 Xorg.0.log_missing_4th_not_confed
< (==) Log file: "/var/log/Xorg.0.log", Time: Sat Jan 5 05:33:09 2008
> (==) Log file: "/var/log/Xorg.1.log", Time: Sat Jan 5 05:59:26 2008
< (**) |-->Screen "Screen_1_-1_scr" (4)
< (**) | |-->Monitor "Formac_mon"
< (**) | |-->Device "Matrox_G400_s2"
< (--) using VT number 7
> (--) using VT number 8
< (--) Chipset mgag400 found
< (II) MGA(0): I2C Monitor info: 0x8257a98
> (II) MGA(0): I2C Monitor info: 0x8253b10
> (==) MGA(2): Removed MMIO write-combining range (0xc6000000,0x400000)
< (II) MGA(2): I2C Monitor info: 0x825db60
> (II) MGA(2): I2C Monitor info: 0x8259c08
So, I am asking for one more screen, and, I get very few more lines.
Created attachment 140156 [details]
/etc/X11/xorg.conf now, that will correspond to Xorg.0.log_missing_4th_not_confed. Here, only 3 screens are configured.
Created attachment 140158 [details]
/var/log/Xorg.0.log_missing_4th_not_confed for actual conf
Created attachment 140160 [details]
/var/log/Xorg.0.log_missing_4th_bug4 when I uncomented Screen 4
The diff have been give in original report: details for the new screen are compleetely missing in the log.
Created attachment 140162 [details]
When I was using X-1.3 ... this config was working fine. Screen 3, the second head of the G400 was called
Screen 1 "Apple_mga_2" LeftOf "Sun_a"
Created attachment 140163 [details]
/var/log/Xorg.0.log_works_2008_01_01 log when using X-1.3 ; as you can see, VGA(1) describes the second head of the Matrox G400. All the part about MGA(1) from this log is now missing when using X-1.4
Now, you see what used to work, and does not work any more.
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 735 Host (rev 01)
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual PCI-to-PCI bridge (AGP)
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS85C503/5513 (LPC Bridge)
00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller
00:02.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 07)
00:02.3 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 07)
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0)
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC'97 Sound Controller (rev a0)
00:09.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo Banshee (rev 03)
00:0b.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2064W [Millennium] (rev 01)
00:0d.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2064W [Millennium] (rev 01)
00:0f.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 08)
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400/G450 (rev 82)
Could you try xf86-video-mga-1.9.100? It's got the new randr 1.2 setup, so multihead configuration will be different. http://www.intellinuxgraphics.org/dualhead.html has some nice examples. Please reopen when you reply.
Created attachment 140755 [details]
It will take time.
Here is an interesting point:
dhp@moon_gen_2:~$ xrandr -q
Xlib: extension "RANDR" missing on display ":0.0".
RandR extension missing
This is really weird ... because, I do use Xinerama ... and randr is acivated (oh, my emerge--info was not attached yet :S shame on me) and it works for 3 of my screens (it works with many limitations, but, I got multihead desktop in front of me). The question is now:
- xrandr flag is set, but command reports it's not acticated; is it required to querry it in the conf like for DRI and Xinerama ?
- if it's OFF, why do I have Randr bugs ?
- if it's ON, why is it reported OFF ?
So, before I do further tests, we need to understand why putting the USE flag is not enough to get the feature ON.
And please, re-read the original report, that mentions that I have 4 major bugs with this X, and, there is a common problem: X does not explicitely report any of them; 1.3 used to be more verbose, and explain why it crashes; 1.4 crashes way quicker, and does not say why, or too rarely for me. Problems:
- crash when asking to use my second Me card (they are identical)
- no more support of 2nd output of MGA400
- garbage on heads 2, 3 and 4 of MGA450
- never any error message, and, log's are too tiny; just compare logs between 1.3 and 1.4, and you will see that they are REALLY shorter about HW detection; this remindes me an old (and still not fixed yet) Xfree problem, on multi bus systems, that did not detect at all cards on bus other than the first main one: you could check lspci, and conf them, they were not even listed in the detection ... (and still are not, when using recent Xorg on the same machines as 10y ago).
My wondering is: are those 4 bugs related ? they may be ... if a part of X miss detects HW, and have poor verbosity ... if its a low level component ...
Somehow, I have 3 different bugs on 3 Matrox cards ! I have to try your driver. But, really, I dont think it will help. Something makes me think it's not a driver problem, but, X internals.
(In reply to comment #6)
> Could you try xf86-video-mga-1.9.100? It's got the new randr 1.2 setup, so
> multihead configuration will be different.
> http://www.intellinuxgraphics.org/dualhead.html has some nice examples. Please
> reopen when you reply.
I dont see how a driver upgrade should induce a différence in my conf.
In your link, I dont see anything that explicitely says there will be anything bad in my conf, conflictuous, or misconfigured.
Testing on way ...
in /etc/portage/package.keywords/common did not let me get it; I always had missing keywords error. I had to copy the ebuild in my own overlay; why didn't it work ?
Created attachment 140938 [details]
X error log when using x11-drivers/xf86-video-mga-1.9.100
I did the test, with "just" upgrading to =x11-drivers/xf86-video-mga-1.9.100 (not recompiling anything else). It failed. I attach the error log.
I did the test while X was running in :0, by executing
xinit -- :1
as usual, as root in console.
I had not change the Xconf yet; this was just a regression test against actual driver, and it failed :) against my actual =x11-drivers/xf86-video-mga-1.4.7
After downgrading again, from 1.9 to 1.4, and re-running the same command at the same place, I can have a working X (still :0 working). Want more logs ? /var/log/Xorg.1.log ? I dont think it's necessary ...
=> 1.9.100 is broken.
forgot to reopen :)
On the 1.9.100 test, did you quit all instances of the 1.4.7 driver first? Your comment suggests that you had 1.4.7 running on :0 and 1.9.100 on :1. If that was the case, don't do that.
(In reply to comment #11)
> On the 1.9.100 test, did you quit all instances of the 1.4.7 driver first? Your
> comment suggests that you had 1.4.7 running on :0 and 1.9.100 on :1. If that
> was the case, don't do that.
Yes, thats what I did;
because doing things any other way make me spend at least half a day, or a full day without X at all, prevents reporting and have "normal life" by side of reporting Gentoo bugs. I will retry as you ask, but, I cant promise any day soon. I also let you know that up to now, any time I do things my way, they fail, and I asked to do things an other way ... it never worked better; so, I would really be surprised that doing this test *your way* will proove I was wrong in keeping X:0 running. Linux is not Windows: all libs are cached, and, X cessions are really independent (having two X running with to different versions never was a problem).
The sessions may be independent, but the ways the device drivers change bits on the video cards are not independent. I would suggest you actually power off the computer for a minute to ensure the video-card state is reset.
I talked to the upstream mga driver developer and he told me there were known Xinerama issues on 1.4.7. It sounds like a 1.4.8 release is happening real soon now so you could also try that once it's out.
I just added 1.4.8, it should be available in an hour or so. Please reopen if that doesn't fix things.
Yes, latest driver fixed my issue; problem is that its months I bought G450 quad, and this one does not work since several X releases ... see bug 210704 .
This fixed for me with X 1.4 two problems:
- missing second head of G400
- systematic fatal crash when asking to use simultaneously both Matrox ME cards (putting two cards, but asking X to use only one was fine).