This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 108073 - MGA dualhead xinerama has odd behaviour.
MGA dualhead xinerama has odd behaviour.
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-27 08:28 EST by Dave Jones
Modified: 2015-01-04 17:03 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-07 22:16:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Config file. (3.61 KB, text/plain)
2003-10-27 08:29 EST, Dave Jones
no flags Details
log file. (54.46 KB, text/plain)
2003-10-27 08:29 EST, Dave Jones
no flags Details
reconfig'd config (3.86 KB, text/plain)
2003-10-27 09:19 EST, Dave Jones
no flags Details
XF86Config from SuSE Liveeval 9.1 which works perfectly. (6.43 KB, text/plain)
2004-05-10 15:03 EDT, Dave Jones
no flags Details
Working xorg.conf under FC2 with HAL driver from Matrox (3.43 KB, text/plain)
2004-09-25 07:12 EDT, Torge Szczepanek
no flags Details
Working xorg.conf under FC2, no proprietary drivers. (3.03 KB, text/plain)
2004-09-29 06:05 EDT, Mark Wilkinson
no flags Details
config generated by display tool (3.44 KB, text/plain)
2005-01-29 12:00 EST, Thomas Vander Stichele
no flags Details
a customized config with hopefully correct labeling (3.84 KB, text/plain)
2005-01-29 12:36 EST, Thomas Vander Stichele
no flags Details

  None (edit)
Description Dave Jones 2003-10-27 08:28:53 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):


How reproducible:
Always

Steps to Reproduce:
1. See description
2.
3.
    

Additional info:
Comment 1 Dave Jones 2003-10-27 08:29:23 EST
Created attachment 95509 [details]
Config file.
Comment 2 Dave Jones 2003-10-27 08:29:46 EST
Created attachment 95510 [details]
log file.
Comment 3 Mike A. Harris 2003-10-27 08:44:38 EST
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?
Comment 4 Dave Jones 2003-10-27 09:19:58 EST
Created attachment 95513 [details]
reconfig'd config

That creates this config file.
Running with this gets me two cloned desktops.
Comment 5 Dave Jones 2003-10-30 08:51:44 EST
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
somewhere.
Comment 6 Dave Jones 2003-12-13 17:12:47 EST
Here's the latest on this bug..

X config looks like this..

Section "ServerLayout"
    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"
EndSection
                                                                     
          
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.
Comment 7 Russell Strong 2004-01-14 17:57:47 EST
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

BusID PCI:1:0:0
Screen 0

and to Videocard1

BusID PCI:1:0:0
Screen 1

it will work ( at least it worked for my G450 ).
Comment 8 Mike A. Harris 2004-01-15 05:20:10 EST
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.
Comment 9 Thomas J. Baker 2004-04-06 14:13:56 EDT
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
problem.
Comment 10 Dave Jones 2004-05-10 15:02:28 EDT
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
or
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.
Comment 11 Dave Jones 2004-05-10 15:03:07 EDT
Created attachment 100140 [details]
XF86Config from SuSE Liveeval 9.1 which works perfectly.
Comment 12 Torge Szczepanek 2004-09-25 07:11:05 EDT
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
/usr/X11R6/lib/modules/drivers.

This works on FC2 for me. Adding the HAL driver to x86_64 does not work.
Comment 13 Torge Szczepanek 2004-09-25 07:12:21 EDT
Created attachment 104314 [details]
Working xorg.conf under FC2 with HAL driver from Matrox
Comment 14 Mike A. Harris 2004-09-25 19:10:14 EDT
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
unfortunately.  ;o(

Comment 15 Mark Wilkinson 2004-09-29 06:02:50 EDT
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.
Comment 16 Mark Wilkinson 2004-09-29 06:05:47 EDT
Created attachment 104500 [details]
Working xorg.conf under FC2, no proprietary drivers.
Comment 17 Torge Szczepanek 2004-10-05 05:57:16 EDT
This is true, when not using DVI output. 

Xinerama with Dual-DVI can only be used when using the Matrox
proprietary driver. (HAL)
Comment 18 Mike A. Harris 2004-10-12 03:39:01 EDT
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?
Comment 20 Dave Jones 2004-11-29 12:56:47 EST
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.
Comment 21 Mike A. Harris 2004-12-22 10:46:16 EST
Did you get it back yet? ;o)
Comment 22 Thomas Vander Stichele 2005-01-29 11:59:05 EST
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
boot time
- both monitors are flatpanel LCDs, Compaq 1520.  AFAIK they are
completely identical.
- 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
wallpaper

- 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
mentioned)
  - switching Device identifiers around in the "Screen" sections made
no difference

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

CONCLUSIONS
-----------
- 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.
Comment 23 Thomas Vander Stichele 2005-01-29 12:00:17 EST
Created attachment 110388 [details]
config generated by display tool
Comment 24 Thomas Vander Stichele 2005-01-29 12:36:16 EST
Created attachment 110391 [details]
a customized config with hopefully correct labeling
Comment 25 Thomas Vander Stichele 2005-01-29 12:53:30 EST
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
1024x768@60Hz.
- 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 ?
Comment 26 Thomas Vander Stichele 2005-01-29 13:16:28 EST
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 ?
Comment 27 Mike A. Harris 2005-02-07 21:56:45 EST
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:

        http://fedora.redhat.com/download

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

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".
Comment 28 Dave Jones 2005-02-07 22:03:31 EST
https://bugs.freedesktop.org/show_bug.cgi?id=2492

it's still repeatable. btw, UPSTREAM would probably have been a better
closure than CURRENTRELEASE.
Comment 29 Mike A. Harris 2005-02-07 22:15:18 EST
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
case.  ;o)

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.
Comment 30 Thomas Vander Stichele 2005-02-17 03:06:19 EST
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.

Note You need to log in before you can comment on or make changes to this bug.