cyber9320 on the Thinkpad 365X[D] DSTN - "orange lines" and system crash/freeze
Submitted by James
Assigned to Egbert Eich
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.