Bug 59956 - S3 Trio3D strange mirroring effect with X
Summary: S3 Trio3D strange mirroring effect with X
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
(Show other bugs)
Version: 7.3
Hardware: i386 Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2002-02-15 22:03 UTC by Don Smith
Modified: 2007-04-18 16:40 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-07-26 08:55:00 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
XFree86 config file (3.70 KB, text/plain)
2002-03-11 20:00 UTC, Don Smith
no flags Details
XFree86 log file (25.94 KB, text/plain)
2002-03-11 20:00 UTC, Don Smith
no flags Details

Description Don Smith 2002-02-15 22:03:33 UTC
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:

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:

Comment 1 Mike A. Harris 2002-03-11 06:03:05 UTC
Please attach Xfree86 config file and log file using the link below.

Comment 2 Don Smith 2002-03-11 19:54:09 UTC
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 

I will attach the config and log files shortly.

Comment 3 Don Smith 2002-03-11 20:00:20 UTC
Created attachment 48185 [details]
XFree86 config file

Comment 4 Don Smith 2002-03-11 20:00:57 UTC
Created attachment 48186 [details]
XFree86 log file

Comment 5 Wendy Hung 2002-03-27 16:35:09 UTC
Not fixed in Beta3(skipjack).

Comment 6 Wendy Hung 2002-04-11 15:58:49 UTC
Not fixed in Hampton beta4 (skipjack2).

Comment 7 Mike A. Harris 2002-04-13 23:37:05 UTC
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.

Comment 8 Mike A. Harris 2002-04-13 23:38:20 UTC
Try Xconfigurator --preferxf3 as well if it hasn't been tried already.

Comment 9 Don Smith 2002-05-07 15:09:24 UTC
This problem doesn't exist with XFree86 3.3.6a (included with RH7.2)

Comment 10 Mike A. Harris 2002-05-07 19:11:09 UTC
Try option "noaccel" also.

Comment 11 Don Smith 2002-05-07 20:12:29 UTC
"noaccel" had no effect (except to make things slower ;)

Comment 12 Mike A. Harris 2002-06-22 03:20:54 UTC
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.

Comment 13 Don Smith 2002-07-24 13:35:18 UTC
The VESA driver works just fine, whether or not I use the framebuffer console.

Comment 14 Mike A. Harris 2002-07-26 08:54:54 UTC
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.

Comment 15 Mike A. Harris 2002-07-26 09:42:40 UTC
Driver default changed to "vesa" in hwdata-0.35-1 in rawhide.

Comment 16 Mike A. Harris 2004-08-30 06:00:12 UTC
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.

Comment 17 Don Smith 2004-08-30 15:49:49 UTC
If I can find a old system here with that video chipset, I'll give it
a try.

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