Bug 42033 - XFree86 version 4.0.3 doesn't work for my Trident Cyber 9388
Summary: XFree86 version 4.0.3 doesn't work for my Trident Cyber 9388
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
: 44753 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-05-23 20:10 UTC by D. Hugh Redelmeier
Modified: 2007-04-18 16:33 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-11-05 15:48:21 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
XF86Config-4 created by installation of RHL7.1 (3.70 KB, text/plain)
2001-05-23 20:13 UTC, D. Hugh Redelmeier 		no flags Details
log of startx (12.17 KB, text/plain)
2001-05-23 20:19 UTC, D. Hugh Redelmeier 		no flags Details
Add an attachment (proposed patch, testcase, etc.)

Description D. Hugh Redelmeier 2001-05-23 20:10:28 UTC 
Description of Problem:

Screen on my NEC Versa SX notebook when I start X after my RHL7.1 install.
XFree 3.x worked fine on RHL 6.2 on the same computer.

I've tried many combinations of options, bpp, and resolution.  The mess
shows up on the built in display and on an external monitor.

The pixels may all be there -- I can make out some of the parts of the
screen -- but they seemed to be interleaved in some way.

I've noticed a couple of other folks with Fujitsu Lifebooks (with the same
video chip) having problems with XFree86 4.0.3.  They ended up running the
version 3 server on their RHL 7.1 system.  I'll try that when I've figured
out how.

How Reproducible:
Always

Steps to Reproduce:
1. startx
2. 
3. 

Actual Results:
unreadable screen
The rectangular cloud that is the cursor seems to occupy roughly 64 pixels
by 64 pixels.  Other transformations are harder to make out.

Expected Results:
normal desktop

Additional Information:
	
Testing X *during* RHL7.1 installation worked!
Comment 1 D. Hugh Redelmeier 2001-05-23 20:13:22 UTC 
Created attachment 19450 [details]
XF86Config-4 created by installation of RHL7.1
Comment 2 D. Hugh Redelmeier 2001-05-23 20:19:45 UTC 
Created attachment 19452 [details]
log of startx
Comment 3 D. Hugh Redelmeier 2001-05-24 21:42:37 UTC 
My problems were with the 4.0.3 trident server installed by the standard
installation of RHL7.1.  After my bug report (42033), I installed
the SVGA server from RHL7.0's 3.3.6.
	rpm -i XFree86-SVGA-3.3.6-33.i386.rpm
To build appropriate config files, I used:
	Xconfigurator --preferxf3
It turns out that a version of this RPM is also on the 7.1 distribution.

This worked.

See also bug 41150
Comment 4 Mike A. Harris 2001-05-24 22:46:38 UTC 
I'll ask upstream if anyone has any ideas about this because I have no
Trident hardware or docs.
Comment 5 Mike A. Harris 2001-11-05 12:57:43 UTC 
*** Bug 44753 has been marked as a duplicate of this bug. ***
Comment 6 D. Hugh Redelmeier 2001-11-05 15:48:15 UTC 
I installed RHL7.2 on the same hardware.  XFree86-4.1.0-3, as installed, worked
perfectly.  Not heavily tested, but clearly better than 4.0.3 and even 3.3.6. 
Looking at the log from startx, it seems to be loading the module trident_drv.o
to run the screen (but it is also loading libfbdevhw.a).  I could attach the
log, but I would guess that it doesn't matter since everything appears to work.

Thanks.
Comment 7 Mike A. Harris 2001-11-06 03:30:23 UTC 
Cool, glad it is working now for you.  I'll close the bug resolved in
RHL 7.2.  There are some more Trident fixes coming in 4.2.0 in the
future also.
Note You need to log in before you can comment on or make changes to this bug.