Red Hat Bugzilla – Bug 108073
MGA dualhead xinerama has odd behaviour.
Last modified: 2015-01-04 17:03:39 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031023
Description of problem:
With a Matrox G550, getting dual head working correctly is something of a struggle.
First, I get nothing (no signal at all, monitor is in standby) on head 2 unless
I comment out the line that reads
Screen "Screen2" RightOf "Screen1"
If I then uncomment it, and restart X, I get Xinerama, but the heads are the
wrong way around. (Head1 is on the right hand monitor (CTX in my case), and
head2 is on the left (Dell))
Switching around the entries
Device "Matrox G550 head2"
Device "Matrox G550 head2"
in the Screen sections makes no difference at all.
Changing the ServerLayout to Screen2 LeftOf Screen1 doesn't make any difference.
Changing the screen numbers in the Device section makes no difference.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. See description
Created attachment 95509 [details]
Created attachment 95510 [details]
If you run back up your config, and then run "redhat-config-xfree86 --reconfig"
and configure dualhead in the config tool, is there any change?
Created attachment 95513 [details]
That creates this config file.
Running with this gets me two cloned desktops.
ok, so the...
Option "Xinerama" "on"
Actually belongs in a ServerFlags section. Doing this got me a xinerama desktop,
but the heads were the wrong way around. No amount of fiddling with the LeftOf /
RightOf definitions made a difference.
I even installed the mga powerdesk utility and fiddled with that to no gain.
Eventually I gave up and switched the ports the monitors were plugged into on
the back of the card. I'm now happy, but it sounds like something isn't right
Here's the latest on this bug..
X config looks like this..
Identifier "Matrox PowerDesk configured."
Screen 0 "Display 1" 0 0
Screen 1 "Display 2" RightOf "Display 1"
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "DevInputMice" "AlwaysCore"
This boots up in dual head mode, but monitor 0 is powered off.
If I disable the line which says
Screen 1 "Display 2" RightOf "Display 1"
with a #, and restart the X server, monitor 0 powers up,
and I get a cloned desktop. If I then uncomment that line,
and restart X again, I get a dual head xinerama display as
I expect to see it.
I've had the same problem with a G450. The problem I found was in the
Device section, and the component that this bug should possible be
against is redhat-config-xfree.
redhat-config-xfree produces "Device" sections without a Screen
parameter. If you add to Videocard0
and to Videocard1
it will work ( at least it worked for my G450 ).
I can confirm that Russell's suggestion is absolutely required on
dualhead Matrox setups, all Radeon hardware, and any other hardware
which has multiple heads integrated into one piece of hardware.
redhat-config-xfree86 should always configure multiple heads on one
device, using the "Screen n" option, as it isn't optional in such
configurations, but required for proper operation.
However, Dave's config file contains those options already, so I
don't think that is the problem for his issue.
I can corroborate Dave's findings exactly. After a reboot, with an MGA
G550, X doesn't come up in a dual head configuration when so
configured. The same tricks he used (comment out one head, start X,
uncomment it) works to fix it. Looks like some type of initialization
Another data point. I just booted a SuSE 9.1 liveeval CD, and it
picked up both heads, and did the right thing, even got them the right
way around. I took the XF86Config it generated, and butchered it into
a Fedora xorg.conf. (Basically took the SuSE config except for the
"Files" section). It still broke.
This leads me to believe its either
a) A patch against our X we apply that SuSE don't that is broke
b) A patch SuSE apply that we don't that fixes this
c) A fix from a different version of X. (Unlikely given theyre both
from the same x.org release afaik).
I'll append the config, though after seeing that this config works on
SuSE but not on Fedora, I'm convinced this isn't a config issue any
more, and something more deep seated.
Created attachment 100140 [details]
XF86Config from SuSE Liveeval 9.1 which works perfectly.
I have the same problems using Fedora Core 2.
This can be fixed by downloading the Xfree86 4.3.0 Matrox HAL driver
from www.matrox.com and putting mga_drv.o and mga_hal_drv.o in
This works on FC2 for me. Adding the HAL driver to x86_64 does not work.
Created attachment 104314 [details]
Working xorg.conf under FC2 with HAL driver from Matrox
davej: If I'm not mistaken, SuSE ships the proprietary Matrox
hallib I believe, which Torge mentions works around this in
comment #12 above.
torge: The hallib binary is an i386 compiled module, so it wont work
as a workaround for AMD64 or any other architecture other than i386
Hrrm; I'm puzzled by this bug. I'm running Fedora Core 2 and have a
G550 driving two screens quite happily. I'm using a handwritten
xorg.conf based on the one I used under XF86, and my system goes
straight into dual head mode with Xinerama first time every time. This
is without the proprietary Matrox drivers installed, too.
Created attachment 104500 [details]
Working xorg.conf under FC2, no proprietary drivers.
This is true, when not using DVI output.
Xinerama with Dual-DVI can only be used when using the Matrox
proprietary driver. (HAL)
Dave: Does the config from comment #16 work for you in FC2 or
FC3t2? Also, are you using 2 CRTs, 2 DFPs, or a mixed lot?
its going to be another few weeks before I get the box with my g550
back. Will test as soon as I get it back.
Did you get it back yet? ;o)
I'm going to add my data points as well. Over the last year I've
tried several times to get the setup working the way I would like it
to, and it failed every time. I'm pretty sure this worked fine in
FC1, and hasn't worked since.
First, the hardware:
- card is a matrox g550, first head is a VGA port, second a DVI port.
I call the VGA port the "first" because it is the only one active at
- both monitors are flatpanel LCDs, Compaq 1520. AFAIK they are
- the left LCD (hereby known as LCD1) is connected to VGA (I like to
think of the "card output that shows boot info" as "first" and
"left"), the right LCD (from hereon known as LCD2) is connected to DVI
using a DVI-to-VGA dongle
Second, the initial config:
- fresh FC3 install + updates
- activated dualhead in the display configuration
- restarted X
- mouse pointer starts centered on LCD2
- panel and splash screen show up on the LCD2
- nautilus icons show up on LCD1
- wallpaper wraps around from LCD2 to LCD1
(I am going into detail on these items because they actually change
in different configs, which probably indicates some of the gnome libs
have differing concepts of what is "the primary screen")
- mouse wraps around, going from the right-hand-side of LCD2 to the
left of LCD1, which means the right monitor is the left-hand-side of
my virtual xinerama desktop
- conclusion: if I'd switch the LCD's around physically it'd be
correct. Which I don't want to do, because as I said, LCD1 should
show me both the boot info and be the "primary" X screen.
- ideal solution: some way of having X swap the screens around, so
that what it's currently showing on DVI and LCD2 is the *secondary*
screen, and the right-hand side of my virtual desktop
(I'm attaching this generated config as xorg.conf.multihead)
third, the fiddling:
- A) changing LeftOf to RightOf:
- mouse pointer starts centered on LCD2
- the mouse pointer now scrolls sanely; instead of wrapping around
the edges, it goes from the left screen to the right screen
- however, panels and splash screen still start up on LCD2
- nautilus icons moved to LCD1 (!)
- wallpaper now spans LCD1+2 correctly
- this behaviour leaves me completely confused as to what X thinks
is the "primary" screen (which I assume would be the one that has
splash and panels) My best guess is that the "primary" screen is the
one that has the first "Screen" parameter in the ServerLayout Section,
and that Screen0 is somehow tied to LCD2 and the DVI port.
- B) building on the idea of "Screen0 -> LCD2", I changed serverlayout to
Screen 0 "Screen1" LeftOf "Screen0"
Screen 1 "Screen0" 0 0
hoping it would take LCD1, make it the primary, and put LCD2 to the
right of it
- result: same as initial; pointer on LCD2, panel and splash on LCD2,
nautilus icons on LCD2, mouse wraps around from right to left, as does
- C) trying to switch around the devices:
- changing Videocard0 to Videocard1 in the first device section and
the other way around in the other made no difference whatsoever
- putting the videocard1 section in front of videocard0 made no
difference (I was hoping that maybe devices were probed in the order
- switching Device identifiers around in the "Screen" sections made
fourth, I customized the config completely based on a web page I
found, and trying to label items according to the physical situation.
(This config is attached with the hopeful name of xorg.conf.multifixed)
I did one customization here; one screen is set to 800x600, the other
to 1024x768. I have the feeling X.org is confusing some entries or
not labeling them correctly, so this is an additional test to check
what entries might be wrong.
Starting with this config file:
- mouse pointer starts on LCD2
- the panel and splash start on LCD2
- the nautilus desktop icons are on LCD1
- the mouse pointer and wallpaper span correctly
- LCD1 is in 1024x768
- LCD2 is in 800x600
- mouse pointer, gnome-splash and gnome-panel have a different concept
of "the primary screen" than the background and nautilus
- I found no way to have pointer, splash and panel start on LCD1 at all
- My guess would be the root problem is there's no reliable way to
decide what device ends up taking the VGA port, and what the DVI port.
I'd really really like to help fix this for FC4, it annoys me
incredibly. If there are more tests I can do, let me know.
Created attachment 110388 [details]
config generated by display tool
Created attachment 110391 [details]
a customized config with hopefully correct labeling
some other related behaviour that I haven't been able to figure out:
A) with the original config (ie, a single head config, which
automatically "cloned" to LCD2), I saw:
- on boot, only LCD1 shows BIOS info
- while starting kernel, only LCD1 shows info
- when rhgb starts, it shows up on both screens
- gdm spans both screens
- the desktop spans both screens
- when switching back to console, suddenly LCD2 also has a text console
B) during experimenting with various configs, on a terminal:
- sometimes, LCD1 would show no signal, asking to switch the PC to
- sometimes LCD1 would show the console, but with all characters
stretched and ugly (like on some laptops that allow you to "stretch"
the 640x480 modes to fullscreen)
- sometimes LCD1 would be "fixed" to normal display
I have no idea exactly what triggers which of these behaviours
C) All of the multihead changes were done from the same kernel
session, ie without rebooting once. After a reboot where the last
config was a multihead, LCD2 *never gives signal* anymore when using
the multihead config. Worse, after leaving X again, it also leaves
LCD1 unusable, asking me to switch the PC to 1024x768@60. So, at that
point, I have *no usable LCD's* anymore.
Logging in with ssh, switching the config back to the single head
config, then starting X again, activates both LCD1 and LCD2 in a clone
mode. Leaving X after that leaves LCD1 unusable, and LCD2 usable.
Switching back to a multihead config, then starting X, shows both
LCD's usable again (but still not configured correctly). Quitting X
gives me a usable (but ugly-stretched) LCD1, and a usable LCD2. Phew :)
Are there tools around that do some of the video device ocnfiguring
that X.org obviously does in the different modes ?
some additional information. When using the multifixed config, and
dropping in mga_drv.o and mga_hal_drv.o from matrox's site (the
december version), X works as expected. mouse, desktop icons, panel,
splash all show up on the left screen. mouse wraps correctly. When
leaving X after switching to these drivers, LCD1 now has a correct
console, while LCD2 for the first time doesn't.
After rebooting, it still works in this multihead config. Obviously
the mga_hal_drv.o are rerouting some connections on the card. I
remember from my days of experimenting with the G400 and TV/Out, there
was a matroxset tool that allowed you to route the "internal" two
display drivers to either one of the "external" connectors. Maybe
this is exactly the sort of thing that needs to be added to X.org ?
Since this bugzilla report was filed, there have been several major
updates to the X Window System, which may resolve this issue. Users
who have experienced this problem are encouraged to upgrade to the
latest version of Fedora Core, which can be obtained from:
If this issue turns out to still be reproduceable in the latest
version of Fedora Core, please file a bug report in the X.Org
bugzilla located at http://bugs.freedesktop.org in the "xorg"
Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes that
become available for consideration in future updates.
Setting status to "CURRENTRELEASE".
it's still repeatable. btw, UPSTREAM would probably have been a better
closure than CURRENTRELEASE.
Thanks for the update Dave. We only put bugs in "UPSTREAM" state
when a bug report has already been filed upstream by the reporter,
or if someone indicates in the bug report of a pre-existing upstream
bug that we can use to track.
"CURRENTRELEASE" was chosen, under the assumption the problem is
resolved in FC3 or later, and that the report would get updated by
those having the problem (as you've done), if that was not the
Now that we know the issue is still present, and there's an upstream
bug report to track, I'm changing the status to "UPSTREAM" and
adding myself to CC there.
Thanks again for the update.
whotsthisallmean ? Should I copy all my painfully extracted wisdom by
inflicting harmful testing on myself over there ? Should I link in
that fdo.bug to this bug ? Guide me oh master for I have lost the light.