Created attachment 89453 [details]
XFree 86 log

Bugzilla wont let you cut and paste it because you're not supposed to
cust and paste large files into the bug report text. It makes them very
huge and unreadable after several comments.  Always use file attachments.

Please test the following things in order, and let me know which one works
better (if any):

Put the following line in the Device section of your config:

    Option "noaccel"

Restart X, and see if it makes any improvement at all.  If it does not,
try running "redhat-config-xfree86" and changing the driver to the "vesa"
driver.

Please let me know the results of these two tests.

Wow,you're good!  noaccel had no effect but using the vesa driver seems to have
cured the problems.  Since it worked in RH7.0, I guess that means there is a
problem with the latest version of the s3virge driver from XFree86????

Is there any disadvantage to using the vesa driver permanently?? Like maybe
performance, functionality, etc.???  Should I put a bug report into XFree86.org???

thanks for the help,

Harry

The "s3virge" driver was never used by default for this card in the past
releases.  Instead, the XFree86 3.3.6 X server was used by default.  As
such, the s3virge driver was never widely tested, and bugs tended to not
get reported, so they never got fixed by XFree86.org either unfortunately.

Now that we no longer ship XFree86 3.3.6, all hardware which used to default
to it, has been changed to default to the native 4.x driver instead during
our beta testing.  Cards that are unsupported by the 4.x native drivers
default to the "vesa" driver now.  Cards that are reported to us to not
work, which things like "noaccel" do not resolve, and to which we are
unable to fix ourselves due to lack of hardware, docs, prioritization of
issues, and other reasons, we default to the "vesa" driver if it turns
out to work.

Using "vesa" for cards that we can't fix, or don't have the resources
to do so, and which XFree86.org doesn't fix or wont fix, allows us
to give a user working video out of the box by default rather than
nonworking video.  Unfortunately, we don't have all of the various
video cards out there, in particular a lot of older ones, so for older
hardware, we rely on our beta testers, users, and customers to run our
beta test releases during development, and report bugs to us, and
problems such as the above.  When someone reports an issue during
beta testing, we often can fix things or workaround problems on a
given video card before the OS goes gold.  However, if a particular
video board doesn't work, and nobody reports it to us in time, then
the OS might end up shipping with broken video on the lesser used
chips and legacy video.  This has shown to be the case with a fair
amount of S3 hardware unfortunately.  ;o/

>Is there any disadvantage to using the vesa driver permanently?? Like maybe
>performance, functionality, etc.???  

Yes, the "vesa" driver uses the video card's BIOS to set up video modes,
etc. and as such is not accelerated.  Video is noticeably slower when using
vesa.  Also, some features of a video card may be unavailable, such as
3D acceleration, Xvideo support, and other features.

>Should I put a bug report into XFree86.org???

Sure, never hurts.  You can report it to xfree86@xfree86.org if you like.
You might not get a response, but it lets them know the card isn't working
still.

Hope this helps.  Take care!


This allows us to give the user a better 

I tried to view bug# 82783 and Bugzilla says I'm not authorized to view that
bug.  What's up with this??  I'd like to be able to view "any" bug in the
system.  Are there "secret" bugs that can't be viewed??

thanks,

Harry Paul

Bugzilla is a Red Hat internal development tool.  Red Hat has decided a long
time ago to allow the general public to also have access to reporting bugs
and querying the parts of the database that are public.

Bugzilla does not contain just publically reported bugs, it also contains
private bug reports filed by Red Hat partner companies and hardware vendors
which contain private information under non-disclosure agreements.

Bugzilla also contains developer's personal private todo list items, tracking
bugs and other private information.

A lot of these private bugs are either uninteresting to the public, or
are not intended for the public at all due to containing private information
or personal information, security related issues that are not public, or
other items.

Keeping track of this information in 8 separate databases is not beneficial
for the purposes of data separation, so it is kept in one database, and
private information is flagged as private to a certain group or groups
of bugzilla users.

In general, any bug that does not contain private information is
marked public.  Also, bugs that private information is no longer
needed to be private, get changed to be public over time.

I hope this helps to clarify why some bugs are publically viewable, and
other bugs are marked private.  

Does what you see on screen look anything like these pictures:

ftp://people.redhat.com/mharris/pictures/RageIIC

No.  In those pictures you are able to see what "type" of information is
actually on the screen.  With my problem, the screen flares really bright and
you cannot see any form of data on the screen.  Just a really bright screen with
what looks a bad tv screen that needs demagnetizing (if you've ever seen one of
those).  And even when you do a ctl+(=)equal to shut down X, you still can't see
anything on the screen.  My screen will be a really bright white with blues
fringes around the edges but it also will roll and split.  You can't see any
data at all, even though it probably is still there.

Harry

If you were referring to the screen "flicker problem" I have, it is not like the
pictures either.  My screen data is very clear but the screen (when it isn't
black on white, or white on black, has what looks like a 30-50hz flicker
throughout the color part of the screen. Then when you shut down X to go back to
terminal window, the screen begins the flaring and the screen won't be normal
again until you shut down the system and reboot.  

Harry
 

Please upgrade to Fedora Core 2 or later, and if this issue turns
out to still be reproduceable, please file a bug report in the
X.Org bugzilla located at http://bugs.freedesktop.org in the
"xorg" component.

Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes
that become available for consideration in future updates.