Bug 20659
| Summary: | (Trident Cyber 9525) Exiting X garbles display beyond repair | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Bernhard Rosenkraenzer <bero> | ||||||
| Component: | XFree86 | Assignee: | Mike A. Harris <mharris> | ||||||
| Status: | CLOSED RAWHIDE | QA Contact: | David Lawrence <dkl> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 7.0 | CC: | alanh, brent, hno | ||||||
| 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: | 2001-11-06 03:54:04 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: |
|
||||||||
|
Description
Bernhard Rosenkraenzer
2000-11-10 20:37:00 UTC
Is this still repeatable with 4.0.3 now Bero? *** Bug 51695 has been marked as a duplicate of this bug. *** Can't tell - the hardware broke down early this year (in January). Let me know what I need to load to test it on 4.0.3 and I'll test it out on my system. I didn't have this problem when I was running RedHat 7.1 on the system, it wasn't until I loaded the beta that this problem came up... This happens to my Thinkpad 760EL which has a cyber card (a 9320 I think). I've also posted a related comment to bug 18773 because I can't get an XFree86 display at all using the trident server. The trident server in XFree86 4.0.1 through 4.0.3 is broken and needs fixing. Is anyone on the XFree project looking into it, or can we have the SVGA server back? The SVGA server never left in the first place. Install it, and
do Xconfigurator --preferxf3. All releases of Red Hat Linux 7.0, 7.1
and current beta of 7.2 still contain XFree86 3.3.6 servers on the CD's
for backwards compatibility.
The bugs exist for 3 very good reasons.
#1) Trident will not release specifications for their hardware
#2) I have access to zero trident hardware
#3) Nobody else seems to have access to the required information any longer
aparently either.
I suggest you fill out a detailed bug report directly with XFree86 instead:
http://www.xfree86.org/cgi-bin/bugform.cgi
I'm leaving the bug open until I can reconcile all open Trident bugs
and attempt another man hunt. ;o)
Changing QA contact to dkl Can only confirm that the problem sort of still exists in XFree 4.0.3. Cyber 9525 chipset (ToshibaSatellite Pro 4220 XCDT) The install procedure finds all fine. No complaints there. If I switch from X to a virtual terminal or suspend, then switching back to X is not an option (only shows some fireworks). Using the old XFree 3.x driver works, but feels a lot slower. So does using the fbdev driver if one adds -noreset to /etc/X11/xdm/Xservers. The fbdev driver also feels very slow compared to the native 4.0.3 driver. Sorry. I meant XFree 4.1.0. My problems with suspend or VT switch is fixed in the current CVS version (what is to become XFree86-4.2). I have backported selected portions of the driver to the RedHat XFree86-4.1 tree and it solved my problems. Patch attached shortly. Created attachment 36301 [details]
Trident driver update for XFree86-4.1 to fix Cyber 9525
I have looked at the attached patch. For the most part, what it is doing is just blocking out various code sections by #if 0 blocks in the acceleration code. IMHO, this is not a proper fix, but rather just a hard coded workaround. The already available Option NoAccel or the various Option "XAANo...." options should more or less accomplish the same via the config file rather than a hard coded disable. Just curious, of the origins of this patch. I have carbon copied Alan to comment on this patch as well. Currently, I am not comfortable with applying this patch. Actually I was unable to CC Alan Hourihane on the last submission. I am looking into that though, and will try to get his comment on the patch updated in here also. The patch is a basically diff beween HEAD and the xf-4_1-branch, with the addition of new cards and API changes excluded. The "#if 0" sections are only a cleanup done in HEAD. These functions are not actually used. It is perfectly safe to exlude those parts of the patch if you like. If you want I can collect and test a more limited patch for you. Regards Henrik Alan, could you look over this patch and comment wether or not it should be safe to apply to 4.1.0? I still think it isn't buying anything more than XAANo.... options. I wont add code that adds support for new chips at this stage, only bugfixes to existing support. New chip support should go into 4.2.0 only. Created attachment 36426 [details]
Trident Cyber 9525 patch, isolated
Perhaps you feel more comfortable with this patch. This has been fixed in the CVS code in exactly this way. Ok, this second patch is much more acceptable. Applied to 4.1.0-6.0.1, will be in -7 release. If it was not fixed in CVS the exact same way I would be very worried as the patch is no more than a backport of the current CVS changes to 4.1. Started with a backport of most of the changes, now isolated to the specific change needed to fix the problem discussed. Patch added to XFree86-4.1.0-6.0.1 and later. Please test, when I get it onto ftp://people.redhat.com/mharris/testing/bleeding-edge Should be before the weekend. Thanks. Ok, this second patch is much more acceptable. Applied to 4.1.0-6.0.1, will be in -7 release. Have been looking out for this new release to test it, but cannot find it anywhere.. not in your bleeding-edge/XFree86 directory, not on rawhide.. Regards Henrik |