Red Hat Bugzilla – Bug 54668
Funky glitches with Matrox Millenium G200
Last modified: 2007-04-18 12:37:37 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.3-12 i686)
Description of problem:
Something is subtly wrong with the Millenium G200.
I get glitches of white around the screen when, for example,
I create a gnome terminal, and move it around on the screen.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
2.Create a GNOME terminal window
3.Move the window around on the screen
Actual Results: Lots of little white dashes appear glitching up the
Expected Results: Moving the window should not create glitches.
THis is on an HP Vectra VEi8 system and an HP P90 monitor.
This problem does not happen with XF86 v3. (But V3 with the G200
has a problem with the monitor. One has to set generic monitor
1280x1024 60Hz. Attempts to drive the monitor under V3 at its rated
speed caused the monitor to complain it was being over-driven. So
I suspect that there was a problem that has been improved upon between
V3 and V4 that is not fully resolved.)
Created attachment 34143 [details]
Created attachment 34144 [details]
XF86Config v4 file
Created attachment 34145 [details]
Log file documenting state of server and monitor.
Ok, I want you to try something to see if the problem goes away for
debug purposes. If you use: Option "Noaccel" as documented on
the "man XF86Config" manpage, does the problem disappear? Make
sure you edit the right config file XF86Config-4.
Ok: Here is what I learned:
* 1. man page enhancement suggestion:
The XF86Config man page implies that you put 'Option "NoAccel"' in the
"ServerFlags" section. If you put it there, it's ignored.
The mga man page never says where to put options, but I guess the
reader is supposed to infer that since "Device" is the only place
options are discussed, that options belong there. Suggestion:
State explicitly that "NoAccel" needs to be in the "Device" section.
State this both in the XF86Config man page, and in the individual
* 2. Disabling acceleration does NOT fix the problem:
But it does change what you have to do to repeat the problem. (Opaque
moves occur so slowly that there is no chance to glitch.) New repeat by:
1. Open a GNOME Terminal window. (easiest to observe if it's pretty much
the only thing on the screen. I put mine in the upper left hand corner,
and I had it be 80x48 in size with font
-misc-fixed-medium-r-semicondensed-*-*-120-*-*-c-*-iso8859-9 when I
2. Use ^f and ^b to rapidly scroll through a large file in vi.
3. Watch occasional glitches off to the right.
*3. I have proof the problem is, as I theorized, with how XF86 is
driving the HP monitor.
I re-enabled acceleration to make the problem as bad as I could.
Then I re-ran XF86Config, saying "no" to the offered HP monitor spec,
and instead selecting "Generic 1280x1024 60Hz".
Opague moves are FAST (so I know Acceleration is re-enabled)
but there is NO glitch.
Version 3.6, when told to drive the HP monitor at its factory specs
caused the monitor to go into power save from being over-driven.
Version 4.0.3 improved on the situation, but something is over-driving
the monitor. The work-around here is to not use the Factory Specs,
but instead to drive the monitor more slowly. If someone knows what they
did to improve on the "drives monitor faster than we think" problem,
they need to go just a BIT further.
Does my explanation make sense?
Are there more test cases you would like me to run to confirm or disprove
I just reviewed the XF86Config files I attached.
The monitor spec shown in the XF86Config-4 file
that I attached is NOT the monitor spec that failed for me.
I apologize for not understanding that Xconfigurator --preferxf3 would
CHANGE XF86Config-4. I'd assumed that when I switched to xf3, it would
leave the -4 file with the failed monitor spec.
Pulling from MonitorsDB, HERE is the monitor spec that was failing:
Hewlett-Packard; HP D2842 HP 90 19-inch Display; hwp0b1a; 30.0-96.0; 50.0-160.0;
Page 15 of the HP90 manual that came with the monitor says:
HP90 with 30-96 and 50-160 is what Xconfigurator offered me.
It's the setup that glitched, under 4.0.3, and what drove the monitor into
power saver mode under 3.6.
Hope this addendum helps.
Again, I apologize for sending a misleading XF86Config-4 attachment.
If you like I can do the inconvenient testing of re-configuring the
with the failed monitor spec, and saving those XF86Config files for
The man page does NOT *anywhere* state that option Noaccel goes in
the serverflags section. It clearly documents the accel option
in the device section, and nowhere does it mention accel/noaccel
in the serverflags section.
Also, we do not write these manpages. The place to request manpage
changes is XFree86.org, as they maintain XFree86 and its documentation.
If you are overdriving your monitor, then that is a configuration problem,
not an XFree86 bug. If Xconfigurator is giving the wrong settings
for your monitor, then I will remove the broken settings from the database.
If you have a Windows .INF file for your monitor, or can get one for it,
I can make sure the config tools autodetect it and/or list it in the dialog
properly in future releases.
Please attach .INF file.
Thanks for the clarification on where to make man page enhancement requests.
I'll follow up with XFree86.org on that issue.
Forgive my being stupid here, but how can a MonitorsDB entry that EXACTLY
matches the parameters of the monitor documented in the manual be bogus?
I guess this could be one of those situations where "you just have to know"
not to drive the monitor at its rated rates, but it seems to me far more likely
that the Matrox driver has a bug in the code that calculates the dot clock.
Regrettably, none of the systems with these HP D2842 HP 90 is running Windows
9x. One of them is running NT, but it seems only to have INF files describing
the video display card. The System32/monitor.INF file contains only code, no
parameters that look reasonable. I'm QUITE ignorant about NT. Perhaps the
monitor parameters are stored some place else, but I could not find them
through the system menus. I'd be glad to search more if you had any suggestions.
P.S. Thanks for picking this bug back up. Sometimes it's a thankless job
trying to sort out all these drivers and monitors, etc.
If this problem is still occuring in Red Hat Linux 9 with XFree86 4.3.0,
please open a bug report on http://bugs.xfree86.org so that many developers
are aware of the issue, and perhaps someone else can reproduce it and fix it.
Closing WORKSFORME for now, as I just tried this on Red Hat Linux 9, and
was unable to observe the problem described.