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:
Created attachment 95509 [details] Config file.
Created attachment 95510 [details] log file.
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] reconfig'd config 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 somewhere.
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.
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 ).
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 problem.
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.
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 /usr/X11R6/lib/modules/drivers. 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 unfortunately. ;o(
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 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.
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 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 ?
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: 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".
https://bugs.freedesktop.org/show_bug.cgi?id=2492 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 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.
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.