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):
Steps to Reproduce:
Actual Results: After probing, "s3" was suggested as the server,
Expected Results: "vesa"-driver should have been chosen for this configuration.
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]
Created attachment 89315 [details]
X -probeonly using vesa driver
Created attachment 89316 [details]
X -probeonly using s3 driver
Created attachment 89317 [details]
Created attachment 89318 [details]
lspci, lspci -n output
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
Thank you for your time,
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
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
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"
Created attachment 89433 [details]
/sbin/lspci -vvvn output for the discussed configuration
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.