Red Hat Bugzilla – Bug 20659
(Trident Cyber 9525) Exiting X garbles display beyond repair
Last modified: 2007-04-18 12:29:46 EDT
Exiting X or switching from X to a text console on a notebook using the Trident Microsystems Cyber 9525 chipset (using the "trident" XF4 module) garbles the display (The screen turns grey and can't display anything anymore).
The computer still accepts commands; blindly logging in and typing startx returns to a usable X session. Switching back to X when it's still running (and was left using Ctrl+Alt+Fx) doesn't help.
Looks like the driver can't switch back to text mode, but kills the video memory while trying.
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
I suggest you fill out a detailed bug report directly with XFree86 instead:
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
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
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
If you want I can collect and test a more limited patch for you.
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
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.
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..