Bug 81659 - redhat-config-xfree86 chooses, after probing, wrong server for S3 Trio64v2, vesa ok, s3 not ok
Summary: redhat-config-xfree86 chooses, after probing, wrong server for S3 Trio64v2, v...
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: redhat-config-xfree86
Version: phoebe
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-01-12 09:11 UTC by Jaakko R
Modified: 2008-05-01 15:38 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-01-24 15:15:42 UTC

Attachments (Terms of Use)
X -probeonly using vesa driver (41.18 KB, text/plain)
2003-01-12 09:18 UTC, Jaakko R
no flags Details
X -probeonly using s3 driver (9.63 KB, text/plain)
2003-01-12 09:20 UTC, Jaakko R
no flags Details
XF86Config file (3.52 KB, text/plain)
2003-01-12 09:22 UTC, Jaakko R
no flags Details
lspci, lspci -n output (859 bytes, text/plain)
2003-01-12 09:24 UTC, Jaakko R
no flags Details
/sbin/lspci -vvvn output for the discussed configuration (410 bytes, text/plain)
2003-01-18 16:24 UTC, Jaakko R
no flags Details

Description Jaakko R 2003-01-12 09:11:23 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i586; U;) Gecko/20021216

Description of problem:

I have a Compaq Deskpro computer with S3 Trio64v2 on motherboard.

For this setup, vesa is the proper XFree driver.  However, installation using
RH-(null) selected the s3-driver, which does not work.  Editing XF86Config-file
solves the problem.

This seems to be known from bugs 64544 and 65651, but maybe some logic in
redhat-config-xfree86 could deduce that this hardware setup should use the vesa

After the installation of (null), I have tried the proper files from RH8.0,
phoebe, and even rawhide.  I did this in hope for improved support in Xfree86,
but apparently it is not there.

A bit confusing is that XFree86-documentation claims that Trio64v2 should work
with internal ramdac.  I do not see any external chip between the S3-chip and
the VGA-connector, maybe just blame my eyes.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.run redhat-config-xfree86
2.do probing

Actual Results:  After probing, "s3" was suggested as the server, 

Expected Results:  "vesa"-driver should have been chosen for this configuration.

Additional info:

Latest versions I tried:
with related packages.

Part of the lspci output:
  00:0f.0 VGA compatible controller: S3 Inc. 86c775/86c785 [Trio 64V2/DX or /GX]
(rev 16)

Comment 1 Jaakko R 2003-01-12 09:18:59 UTC
Created attachment 89315 [details]
X -probeonly using vesa driver

Comment 2 Jaakko R 2003-01-12 09:20:09 UTC
Created attachment 89316 [details]
X -probeonly using s3 driver

Comment 3 Jaakko R 2003-01-12 09:22:48 UTC
Created attachment 89317 [details]
XF86Config file

Comment 4 Jaakko R 2003-01-12 09:24:19 UTC
Created attachment 89318 [details]
lspci, lspci -n output

Comment 5 Jaakko R 2003-01-12 09:56:46 UTC
After filing the bug report, I read the explanation here:


Should the redhat-config-xfree86 have a button "test the configuration", or some
other kind of sanity check so that "X -probeonly" would not give fatal error?

Anyway, I believe that installation should leave a user in a working
configuration, no matter how non-accelerated.  Without a net connection, a user
has difficulties to find out that the particular _ramdac_ is not 'supported'. 
My experience comes from (null), but I believe installing phoebe has the same
side effects.

Thank you for your time,

Comment 6 Brent Fox 2003-01-17 22:11:24 UTC
mharris: so according to your mail, there's no real way for us to detect which
RAMDAC this particular card has, so the 's3' driver will work for some cards but
not others.  

If this is the case, I see two options:
1) Default to the vesa driver for all S3 Trio64 cards
2) Leave it the way it is and have some cards work and some cards not

mharris: if there are any other options that I'm not thinking of, I'd love to
hear them.

Comment 7 Mike A. Harris 2003-01-18 11:06:42 UTC
No, that is not what I'm saying at all.  Different video card chips have
different PCI IDs.  A chip that is supported by the s3 driver more than
likely has a different device ID than one that is not.  That might require
the subvendor/subdevice ID information from cards that do not work in
order to make them autodetect properly.

Doing this allows cards that do work with the s3 driver to use it, and those
that do not work with the s3 driver to use vesa, without penalizing all
s3 users with the slow vesa driver.

Please feel free to reassign all bugs of this type to me (bugs with
errors in chip detection or bad driver selection), as I generally can
resolve these types of issues without too much effort.

I need the complete output of the following command in order to make
this specific card use vesa by default:

lspci -vvvn | grep -A15 "Class 0300"

Comment 8 Jaakko R 2003-01-18 16:24:34 UTC
Created attachment 89433 [details]
/sbin/lspci -vvvn output for the discussed configuration

Comment 9 Mike A. Harris 2003-01-24 15:15:42 UTC
hwdata-0.65-1 has been updated to autodetect this card and autoselect the
'vesa' driver.  Please update this package from rawhide, backup your existing
config file, then run "redhat-config-xfree86 --reconfig" to test and ensure
autodetection is working properly now.  It should use the "vesa" driver.


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