1. First see #13356 2. SVGA makes an etch a sketch with GNOME/KDE in addition to the above noted problems with xfce. Reversion to RH6.2 eliminates the problem. 3. I will run the Xconfigurator of Trond's and see if it improves anything before I revert back to the RH6.2 SVGA server.
Trond's Xconfigurator didnt help any but didnt make anything worse. In every instance reverting to SVGA-3.3.6-20 fixes the problems listed. The SVGA-3.3.6-32 on bootup of GNOME also displays a small grey box on the bottom right-hand side while the "pretty" graphic loads. Then the screen background turns totall gray and etch-a-sketching can commence.
Still exists in RC1, solution still is to revert to RH6.2 SVGA server.
*** Bug 13007 has been marked as a duplicate of this bug. ***
Problem still exits in Rh7.0 and the solution to still to revert to the 6.2 SVGA server. The only improvement is that it is no longer an etch a sketch but now has transparent backgrounds and the screen doesnt clear/refresh. In simple terms if you bring up a window it overwrites the existing data but leaves anything not over written still visible. I would switch this over to 7.0 but the option doesnt exist.
Problem still exists. GUI install/upgrade gives black background and barely readable garbage in info/selection box. Revision from XFree86-3.3.6-33 to XFree86-3.3.6-20 (RH6.2) removes problem yet again. Text upgrade works BTW.
Problem has been fixed with RC1/Wolverine. Took some minor fiddling with Xconfigurator and picking the right custom config of 800x600 at 56hz. I emailed the XF86Config file to the testers list but since it is monitor specific I dont know if it would help anyone else. Boy am I glad this is done... I can now get 800x600 reliably and no etch-a-sketch. If you want the XF86Config file in here just reopen with a NEEDINFO.
*** Bug 24005 has been marked as a duplicate of this bug. ***
Reopening. Seeing screen corruption problem using XFree86-SVGA-3.3.6-35 (latest internal build) at 1024x768x16 which is our test resolution. I would like your config file for trying it a resolution know to work.
Closed due to lack of feedback. The Trident cards are not well supported in XFree86, and this is almost certainly an X server issue. When XFree86 4.1.0 is released, it is possible that the Trident driver may have fixed this problem. If not, please reopen the bug at that time, or file a new bug report.
Created attachment 19090 [details] XF86Config
Created attachment 19091 [details] XF86Config-4
Reopened. Provided config files. Originally mailed to dkl when bugzilla was "unavailable".
Hi Henri, sorry it took me a few days to get to this... I need your X server logs also. In general, both logs and configs are usually needed together. If you use "Xconfigurator --preferxf4 --nodri", what happens?
Created attachment 19553 [details] Requested XFree86 log
Xconfigurator --preferxf4 --nodri doesnt work with my settings
Just a note for future... Trident bugs are pretty impossible to deal with, and are best reported upstream to xfree86 as an email bug report. Egbert Eich is the Trident driver maintainer, and is the only one likely to fix Trident related bugs. I have not Trident hardware, nor trident specifications. Leaving this open, hopeful that this might change - at least for now.
There still seems to be some confusion on this issue. My problems were solved by RH7.1. This ticket was re-opened by dkl@redhat because he was having video corruption problems at higher test resolutions and requested working configs at a know working resolution.
Reclosing bug as henris has indicated his problem is fixed. Only serious security bugs will be addressed in XFree86 3.3.6 from now on as it is totally unmaintained. If anyone else experiences problems, please open a new bug report.