Bug 54668 - Funky glitches with Matrox Millenium G200
Summary: Funky glitches with Matrox Millenium G200
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
Blocks: 82777
TreeView+ depends on / blocked
Reported: 2001-10-15 22:09 UTC by wdc
Modified: 2007-04-18 16:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-04-05 10:56:08 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
XF86Config file (14.52 KB, text/plain)
2001-10-15 22:14 UTC, wdc
no flags Details
XF86Config v4 file (1.83 KB, text/plain)
2001-10-15 22:15 UTC, wdc
no flags Details
Log file documenting state of server and monitor. (18.01 KB, text/plain)
2001-10-15 22:16 UTC, wdc
no flags Details

Description wdc 2001-10-15 22:09:51 UTC
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):

How reproducible:

Steps to Reproduce:
1.Start x
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.

Additional info:

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.)

Comment 1 wdc 2001-10-15 22:14:00 UTC
Created attachment 34143 [details]
XF86Config file

Comment 2 wdc 2001-10-15 22:15:40 UTC
Created attachment 34144 [details]
XF86Config v4 file

Comment 3 wdc 2001-10-15 22:16:23 UTC
Created attachment 34145 [details]
Log file documenting state of server and monitor.

Comment 4 Mike A. Harris 2001-10-21 22:08:54 UTC
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.

Comment 5 wdc 2001-10-23 17:14:21 UTC
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 
man pages.


* 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.

I repeat:

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
my theory?

Comment 6 wdc 2001-10-23 17:41:54 UTC
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:
   Scanning Frequency:
      Horizontal:  30-96kHz
      Vertical:    50-160Hz

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

Comment 7 Mike A. Harris 2002-03-12 08:27:17 UTC
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.

Comment 8 Mike A. Harris 2002-03-12 08:29:30 UTC
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.

Comment 9 wdc 2002-03-12 19:11:13 UTC
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.

Comment 10 Mike A. Harris 2003-04-05 10:56:08 UTC
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.

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