Bug 20659 - (Trident Cyber 9525) Exiting X garbles display beyond repair
(Trident Cyber 9525) Exiting X garbles display beyond repair
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
: 51695 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-11-10 15:37 EST by Bernhard Rosenkraenzer
Modified: 2007-04-18 12:29 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-11-05 22:54:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Trident driver update for XFree86-4.1 to fix Cyber 9525 (17.63 KB, patch)
2001-11-03 11:15 EST, Henrik Nordstrom
no flags Details | Diff
Trident Cyber 9525 patch, isolated (870 bytes, patch)
2001-11-05 05:53 EST, Henrik Nordstrom
no flags Details | Diff

  None (edit)
Description Bernhard Rosenkraenzer 2000-11-10 15:37:00 EST
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.
Comment 1 Mike A. Harris 2001-04-02 13:10:48 EDT
Is this still repeatable with 4.0.3 now Bero?
Comment 2 Mike A. Harris 2001-08-15 07:48:57 EDT
*** Bug 51695 has been marked as a duplicate of this bug. ***
Comment 3 Bernhard Rosenkraenzer 2001-08-15 07:52:03 EDT
Can't tell - the hardware broke down early this year (in January).
Comment 4 Brent Michalski 2001-08-15 10:42:39 EDT
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...
Comment 5 Mark Toner 2001-09-05 15:48:05 EDT
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?
Comment 6 Mike A. Harris 2001-09-05 16:36:31 EDT
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)
Comment 7 Glen Foster 2001-09-06 09:54:10 EDT
Changing QA contact to dkl
Comment 8 Henrik Nordstrom 2001-11-02 14:46:57 EST
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.
Comment 9 Henrik Nordstrom 2001-11-02 15:06:50 EST
Sorry. I meant XFree 4.1.0.
Comment 10 Henrik Nordstrom 2001-11-03 11:12:45 EST
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.
Comment 11 Henrik Nordstrom 2001-11-03 11:15:43 EST
Created attachment 36301 [details]
Trident driver update for XFree86-4.1 to fix Cyber 9525
Comment 12 Mike A. Harris 2001-11-04 23:17:12 EST
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.
Comment 13 Mike A. Harris 2001-11-04 23:18:36 EST
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.
Comment 14 Henrik Nordstrom 2001-11-05 03:42:36 EST
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
Comment 15 Mike A. Harris 2001-11-05 04:49:04 EST
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.
Comment 16 Henrik Nordstrom 2001-11-05 05:53:34 EST
Created attachment 36426 [details]
Trident Cyber 9525 patch, isolated
Comment 17 Henrik Nordstrom 2001-11-05 05:54:07 EST
Perhaps you feel more comfortable with this patch.
Comment 18 Alan Hourihane 2001-11-05 07:12:37 EST
This has been fixed in the CVS code in exactly this way.
Comment 19 Mike A. Harris 2001-11-05 07:54:16 EST
Ok, this second patch is much more acceptable.  Applied to 4.1.0-6.0.1,
will be in -7 release.
Comment 20 Henrik Nordstrom 2001-11-05 08:49:52 EST
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.
Comment 21 Mike A. Harris 2001-11-05 22:53:58 EST
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.
Comment 22 Mike A. Harris 2001-11-06 08:51:49 EST
Ok, this second patch is much more acceptable.  Applied to 4.1.0-6.0.1,
will be in -7 release.
Comment 23 Henrik Nordstrom 2001-11-10 07:07:01 EST
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

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