Bugzilla – Bug 117846
Blank screen after X on Matrox G550 if frame buffer console
Last modified: 2005-09-27 19:37:24 UTC
If the console is started in frame buffer mode (kernel parameter vga=0x31A, YaST's standard setting for my monitor) on a Matrox G550 card the screen will stay blank after X is terminated. It also not possible to switch from X to a console window (<ctrl><alt><F1 .. F6>). The screen will also stay blank in this case, but switching back to X is possible. A monitor which is connected to the card's second head shows a horizontal frequency of zero and vertical frequency far beyond any reasonable value (> 500 Hz). The problem is also present in SUSE 9.3.
What happens at boot-time? Does the framebuffer work before X ist started?
Yes, everything is fine until X is started. Before X ist started, framebuffer works on all consoles. Once X was started, there is no picture on any of the text consoles.
This is really tricky. Please provide your /etc/X11/xorg.conf. You could try: + using other modes with your framebuffer + disabling 3d-acceleration (if enabled) Maby this problem is known and Stefan can give us a clue? I added him to CC. Of course, one could always disable the framebuffer or organize a more decent graphics card if this feature is needed so importantly.
I just talked to someone who ones 2 of these cards himself. This feature is often broken with several cards. He suspects a hardware-defect and told me that there is no fix. Try to use the exactly same resolution and color-depth with X and your framebuffer. It's more likely to work then. If this does not work and you really need that feature, you could also try to use the framebuffer-X-server, which would be more compatible but of course would be poorly slow and would not offer 3d-accel.
You can also try Option "Nohal" in Device section of /etc/X11/xorg.conf.
I tried to set the timings in xorg.conf to exactly the same values which are displayed by fbset -x. Color is 16 bits on VESA console and in X. This time I got a video signal after leaving X but only some colorful block graphics instead of text. Option 'Nohal' is out of bounds as I need the dual head feature of the card (that's why I use it) and as far as I understood it, 'Hal' is required for this case. Strange thing is that the video timings shown by fbset are defenitely out of range for my LCD monitor (digitally connected as 'main' monitor): 77 Hz vertical refresh should not work but it does anyway. Maybe there is the problem: the card does not really work with the timing the framebuffer device thinks it uses. I would have tried the matroxfb, but it is not in the kernel. Is there a reason for this or should I try to compile my own kernel with matroxfb?
Created attachment 50797 [details] xorg.conf file for Matrox G550 in dual head configuration My xorg.conf file. The mode line which is commented contains the values which correspond to the framebuffer timings as displayed by fbset -x. There are two monitors connected: 'main' monitor is LCD 1280x1024, digital 'second' monitor is LCD 1024x768, analog on second head
I'm not sure, whether the "Hal" module is still requrired for Dualhead. Anyway, I would begin to get a single head configuration working and talk about a Dualhead configuration later. It might also help to disable framebuffer completely.
If I replace Option "HAL" with Option "NoHal" I get no picture on BOTH monitors when starting X. The problem seems to be on the X-Server side: it restores any 'normal' VGA mode (eg. 80x25, mode 0x0F00, or 80x50, mode 0x0F01), but no extended VESA mode. By the way: using any 'normal' VGA mode besides 80x25 interferes heavily with console font loading. During startup, the system will switch to 80x25 independend of of the VGA mode which was active before. After X is started and left again, the original graphics mode (eg. 80 x 50) is restored, but now only the upper half of the characters is displayed. But that's another issue... For now it seems that I will get only a text mode console after X, if I leave the card at 80x25. *sigh*
Ok. I close this one as WONTFIX since there is at least a workaround (disabling framebuffer) available. We're aware that the mga driver is in a disastrous constituation, but there is not much we can do about. :-(