In Dualhead Mode (Xinerama on) the xserver stops with mga 1.4.9:
"MGA(0): Unable to map BAR 0. Invalid argument (22)"
this is only in dualhead mode, in single or clone mode, all is fine and working.
as in the following link reported, this seams to be a bug in mga driver.
the patch is available from:
I use this patch and it is working so far on my amd64 system. (i have compiled it as mga-1.4.9-r1
Steps to Reproduce:
1.launch xorg-server 1.5.3-r5 and mga-1.4.9 in dual screen mode
2.error comes after 1-2 seconds
Please convince upstream to even look at the patch, it's not even attached to the upstream bug.
Same problem here. Inactive Xinerame helps getting X to work but both displays show the same.
Until upstream or otherwise solution is available, this ebuild should not bi in "stable".
Created attachment 189677 [details]
ebuild with patch
This ebuild includes the patch mentioned above.
Created attachment 189678 [details, diff]
patch to fix problem wih dualhead
I created a new ebuild that implements the patch mentioned in comment #0. The driver successfully compiled on my system (x86) and I was able to use my dualhead configuration again.
BTW, I also tried version 1.9.100 in portage tree but this does not work as well (X starts but the second monitor is blank).
*** This bug has been marked as a duplicate of bug 267080 ***
Why has this bug marked as a duplicate of bug #267080? Bug #267080 has nothing to do with xinerama and sounds more like a general Xorg+mga problem. Here we have a patched ebuild that should fix the xinerama problem. So please, insert this patched ebuild into portage and then close this bug as fixed.
(In reply to comment #7)
> Why has this bug marked as a duplicate of bug #267080? Bug #267080 has nothing
> to do with xinerama and sounds more like a general Xorg+mga problem. Here we
> have a patched ebuild that should fix the xinerama problem. So please, insert
> this patched ebuild into portage and then close this bug as fixed.
Read again, both bugs are about xinerama. I will apply the patch to portage as soon as I'm able to.
Please, reopen. bug 267080 is not Matrox related, so, this bug can not be dup of it.
Sorry for reopen this bug, but the world updates now use the xorg-server-1.7.6 so i have to use the xf86-video-mga-1.4.11 driver, but same here, same error, same issues.
New patch is available for 1.4.11 at: http://launchpadlibrarian.net/43115869/mga-driver-4.patch
I will try this patch on my work pc, in the next hours.
If you upgrade, disable xinerama or your xserver will not start and you have to fiddle arround !
I will update this bug, as soon, as i have the working verification of the above patc.
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-mga/+bug/292214 Says, that it works (ubuntu users).
Ronny: what is your hardware layout ? single multihead card ? several cards ?
Yes, single Card (Matrox G550 PCIe) Dual-Head
There is an onboard nvidia card, but thats not used.
The patch works in general, but when i start the xserver in xinerama layout and move my mouse to the left (second) Screen, the xorg server freezes (and the complete workstation, too).
So i will now roll back to the xorg-1.6 server with the plain old mga-1.4.9 patched driver, as this is my workstation.
Comments are welcome :)
In related cases, some users reported that swapping the display connectors and adjusting the layout for that made it magically work.
Thanks, that worked quite well :)
But the patch for the mga driver is mandatory for the function of xinerma with mga cards.
This bug still exists in xf86-video-mga-1.5.0. I can confirm that the latest patch at the launchpad.net bug report referenced in comment #10, though developed for xf86-video-mga-1.4.11, also fixes the problem for xf86-video-mga-1.5.0.
The same patch is attached to the upstream bug report (https://bugs.freedesktop.org/show_bug.cgi?id=18472), but upstream seems in no hurry to incorporate it. Gentoo should add the patch to its package in the meantime.
Forget it; Gentoo never dared fixing any X bug I ever had.
Nobody is never in hurry to integrate patches. All dev ask for users to write fixes, but nobody ever include them.
I stopped reporting bugs related to X.
(In reply to comment #17)
> Forget it; Gentoo never dared fixing any X bug I ever had.
> Nobody is never in hurry to integrate patches. All dev ask for users to
> write fixes, but nobody ever include them.
> I stopped reporting bugs related to X.
I can't speak to your situation, but in my opinion there are a lot of bugs filed here that are outside of our expertise. Bugs like this should be filed and handled upstream. Gentoo doesn't want to be in the business of collecting assorted patches, never to go upstream.
I agree completely: ideally, this would be fixed upstream.
In absence of the ideal, no expertise is required -- a patch already exists, has already been tested and confirmed to work by at least three people, and need only be added to the ebuild to fix this bug in Gentoo.
In contrast to Demaine's comments, in my experience Gentoo developers have been far more responsive than anyone at the X.org bugzilla, which is why I started pushing here first rather than there to try to get this patch included. That way at least one distro can be fixed.
So, you want the patch file to be pushed in the ebuild ? That's way too much complicated for a main ! Will take at least 3 years. Start by filling the paper Blue E47 ... you will find it in the Bureau 25A, floor 6 1/2, building 7C. To reach half floors, you need to take the lift Green.
Please test xf86-video-mga-1.6.3 .
Looks to be fixed in xf86-video-mga-1.6.3.