Bug 81659
| Summary: | redhat-config-xfree86 chooses, after probing, wrong server for S3 Trio64v2, vesa ok, s3 not ok | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Public Beta | Reporter: | Jaakko R <jaakkor2> | ||||||||||||
| Component: | redhat-config-xfree86 | Assignee: | Mike A. Harris <mharris> | ||||||||||||
| Status: | CLOSED RAWHIDE | QA Contact: | |||||||||||||
| Severity: | low | Docs Contact: | |||||||||||||
| Priority: | medium | ||||||||||||||
| Version: | phoebe | CC: | bfox | ||||||||||||
| Target Milestone: | --- | ||||||||||||||
| Target Release: | --- | ||||||||||||||
| Hardware: | i386 | ||||||||||||||
| OS: | Linux | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||
| Clone Of: | Environment: | ||||||||||||||
| Last Closed: | 2003-01-24 15:15:42 UTC | Type: | --- | ||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||
| Documentation: | --- | CRM: | |||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||
| Embargoed: | |||||||||||||||
| Attachments: |
|
||||||||||||||
Created attachment 89315 [details]
X -probeonly using vesa driver
Created attachment 89316 [details]
X -probeonly using s3 driver
Created attachment 89317 [details]
XF86Config file
Created attachment 89318 [details]
lspci, lspci -n output
After filing the bug report, I read the explanation here: https://listman.redhat.com/pipermail/xfree86-list/2002q2/000447.html 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, -Jaakko 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. 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. Thanks. |
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 driver? 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): redhat-config-xfree86-0.7.1-4 How reproducible: Always Steps to Reproduce: 1.run redhat-config-xfree86 2.do probing 3. 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: redhat-config-xfree86-0.7.1-4 XFree86-4.2.99.3-20021230.0 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)