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: Always 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 background. 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.)
Created attachment 34143 [details] XF86Config file
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 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 reproduced) 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?
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; 1 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 attachment.
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.