[Bug 2323] New: cyber9320 on the Thinkpad 365X[D] DSTN - "orange
lines" and system crash/freeze
bugzilla-daemon@freedesktop.org
bugzilla-daemon@freedesktop.org
Tue Jan 18 15:41:51 PST 2005
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2323
Summary: cyber9320 on the Thinkpad 365X[D] DSTN - "orange lines"
and system crash/freeze
Product: xorg
Version: 6.8.1
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Driver/Trident
AssignedTo: xorg-bugzilla-noise@freedesktop.org
ReportedBy: james@nurealm.net
The XFree86 trident driver has always had a problem with the Thinkpad 365XD Trident
TGUI 9320 "Cyber" chipset interacting with IBM's DSTN 800x600 LCD. On startup, the
screen would only display two horizontal orange lines and "burn" the LCD, physically
damaging the display - with some recovery over time, as if each section of the dual
scan display had lost the vertical scan signal.
The traditional work-around has been to press Fn and F7, the LCD/external-monitor
switching function, after the X server is started. The result would be a normal
display after a few second delay. This was possible with the XFree86 SVGA driver
version 3.3.6 at least.
The new Xorg trident driver still shows the same problem with the burning orange
lines, but the "Fn and F7" hack has a problem - the system freezes / crashes
instantly. The laptop must be powered down to recover.
Starting with the external display, the situation is the same (without the horizontal
lines of course) - after the X server is started, the screen is blank, and screen
switching freezes / crashes the system, requiring a hard reset.
Starting with the dual display mode is again the same. Starting the X server leaves
both screens blank, with burning orange lines on the LCD. Screen switching to LCD-
only freezes / crashes the system.
Killing the X server without switching displays returns a blank virtual terminal that
can be recovered using "setfont". Leaving the X server for a virtual terminal first,
Fn F7 rotates through the displays normally. Changing back to the X server and,
again, using Fn F7 freezes / crashes the system.
I would infer that this system freeze problem has less to do with the blank X server
startup screen, and more to do with the interaction between the Thinkpad screen-
switching and the Xorg X server.
Trying different trident driver options seems to make no difference. Trying different
bpp options is slightly different. At 16 bpp, instead of 8 bpp - the 365XD has only
1MB of video ram and the driver insists on using a 1024 byte pitch - the X server
starts with a visible display on the left half, and blank or with half-hight vertical
lines on the right half of the LCD, and blank on the external display. Still, trying
the Fn F7 hack fails to switch screens, or, with the option "NoCyberShadow" suggested
in the trident man page, again the system freezes.
Now, the XFree86 version 4 driver has these same problems, so they are inherited.
Something was lost going from version 3 to version 4. What's different? Could
someone please take a look at this. This is a problem here because the vesa bios is
version 1.2 instead of the version 2 needed to use the vesa framebuffer driver.
BTW, the Linux "drivers/video/tridentfb" driver acts similarly, showing the burning
orange lines and blank screen on start up, and freezing the system with Fn F7.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the xorg-bugzilla-noise
mailing list