Description of Problem: Two machines with Trio3D video (IBM x240, Netfinity 7600) have a corrupted display when X is loaded - there is a weird mirroring effect on the right portion of the display. Version-Release number of selected component (if applicable): How Reproducible: always Steps to Reproduce: 1. Choose "S3 Trio3D" for X configuration during install 2. finish install and reboot 3. login and start X Actual Results: weird mirroring effect Expected Results: normal display Additional Information:
Please attach Xfree86 config file and log file using the link below.
I was questioning my sanity as I tried to reproduce this bug again today - I wasn't seeing it until I realized that I wasn't setting a framebuffer mode for the console this time around, which is something I was doing before. It appears that this problem only occurs when you boot in framebuffer mode (vga=xxx parameter). I will attach the config and log files shortly.
Created attachment 48185 [details] XFree86 config file
Created attachment 48186 [details] XFree86 log file
Not fixed in Beta3(skipjack).
Not fixed in Hampton beta4 (skipjack2).
Did this hardware work in a previous release of RHL, and if so, what version of XFree86? 3.3.6, or 4.x, and what version of 4.x? Try option "noaccel" also.
Try Xconfigurator --preferxf3 as well if it hasn't been tried already.
This problem doesn't exist with XFree86 3.3.6a (included with RH7.2)
Try option "noaccel" also.
"noaccel" had no effect (except to make things slower ;)
Please try rebooting without using the framebuffer. Then reconfigure X with Xconfigurator and choosing the VESA generic driver. Does the VESA driver work? If not, please attach config+log from that session as well.
The VESA driver works just fine, whether or not I use the framebuffer console.
Removing block on this bug. It was not set by Red Hat. Whoever set the block on this bug, please do not manipulate our bug block trackers, as it interferes with our internal bug tracking. It is also noticeable to developers (but doesn't show to others). This bug will be resolved shortly however anyway by defaulting this video adaptor to the "vesa" driver which is reported working above.
Driver default changed to "vesa" in hwdata-0.35-1 in rawhide.
I have had a feature request to change the driver of this card from "vesa" back to "s3virge" by 2 users in bug #125866, and will be making the change in the next build of the hwdata package for Fedora Core development. Please test Fedora Core 3 test2 test release once it is released in September, and confirm wether or not the new "s3virge" driver works with your system now or not. If the driver fails for you still in our current sources in Fedora Core 3 test2, could you please file a bug report in upstream X.Org bugzilla for this driver, at: http://bugs.freedesktop.org The video card in both bug reports seems to be completely identical, including subsystem/subvendor ID, so I am assuming the driver may work properly for everyone now. Thanks in advance.
If I can find a old system here with that video chipset, I'll give it a try.