xf86-video-trident issueshttps://gitlab.freedesktop.org/xorg/driver/xf86-video-trident/-/issues2023-02-13T22:57:12Zhttps://gitlab.freedesktop.org/xorg/driver/xf86-video-trident/-/issues/12Default Config: trident driver fails to load: (EE) TRIDENT: Failed to load mo...2023-02-13T22:57:12ZBugzilla Migration UserDefault Config: trident driver fails to load: (EE) TRIDENT: Failed to load module "xaa" (module does not exist, 0)## Submitted by Luke
Assigned to **Xorg Project Team**
**[Link to original bug (#90485)](https://bugs.freedesktop.org/show_bug.cgi?id=90485)**
## Description
Created attachment 115841
bad xorg log
Hello,
First off I have managed ...## Submitted by Luke
Assigned to **Xorg Project Team**
**[Link to original bug (#90485)](https://bugs.freedesktop.org/show_bug.cgi?id=90485)**
## Description
Created attachment 115841
bad xorg log
Hello,
First off I have managed to dust off and boot a very old Compaq Preasario 1200. It runs the CyberBlade/DSTN/i1 chip. By default, running startx causes a hang, this is because it attempts to use non-existent "xaa" module, and for some strange reason, "vesa" instead of trident".
Attached you will see the hanged default xorg attempt at self-configuration.
**Attachment 115841**, "bad xorg log":
[file_90485.txt](/uploads/de0c23a962c7826cc7457c46c95311ac/file_90485.txt)https://gitlab.freedesktop.org/xorg/driver/xf86-video-trident/-/issues/9trident with EXA on xorg-server-1.132018-08-10T20:48:35ZBugzilla Migration Usertrident with EXA on xorg-server-1.13## Submitted by Kyle Evans
Assigned to **Xorg Project Team**
**[Link to original bug (#58841)](https://bugs.freedesktop.org/show_bug.cgi?id=58841)**
## Description
Created attachment 72229
Xorg log w/ EXA enabled, backtrace on exi...## Submitted by Kyle Evans
Assigned to **Xorg Project Team**
**[Link to original bug (#58841)](https://bugs.freedesktop.org/show_bug.cgi?id=58841)**
## Description
Created attachment 72229
Xorg log w/ EXA enabled, backtrace on exit.
Updating my Gentoo system using the trident driver, I've encountered several bugs with the switch to xorg-server-1.13. First,
TRIDENT_Sync Bug: https://bugs.freedesktop.org/show_bug.cgi?id=57996
After the fix for that, trident defaults to XAA, which doesn't exist in 1.13.
Specifying EXA allows the server to start...
Option "AccelMethod" "EXA"
But, when the server is exited the screen goes black and the computer does not respond to keyboard or power button press. ssh works though, and I can start X again, but I can never exit normally.
glx is mentioned in the backtrace, but disabling it results in the same thing.
Gentoo Bug: https://bugs.gentoo.org/show_bug.cgi?id=444406
**Attachment 72229**, "Xorg log w/ EXA enabled, backtrace on exit.":
[xorg.exa.log](/uploads/73d1202e31c3136af28773fa2d38a2f4/xorg.exa.log)https://gitlab.freedesktop.org/xorg/driver/xf86-video-trident/-/issues/8Trident ProVidia 9685 trashed windows @ 24 bpp2018-08-10T20:48:29ZBugzilla Migration UserTrident ProVidia 9685 trashed windows @ 24 bpp## Submitted by David Flater
Assigned to **Xorg Project Team**
**[Link to original bug (#55473)](https://bugs.freedesktop.org/show_bug.cgi?id=55473)**
## Description
Created attachment 67894
Monitor output
X11R7.7
X.Org X Server ...## Submitted by David Flater
Assigned to **Xorg Project Team**
**[Link to original bug (#55473)](https://bugs.freedesktop.org/show_bug.cgi?id=55473)**
## Description
Created attachment 67894
Monitor output
X11R7.7
X.Org X Server 1.12.3
Trident module 1.3.5
(slackware-current / slackware 14.0)
Attempting 1024x768 depth 24 with Trident ProVidia 9685 PCI (Jaton), windows are stretched to the right and trashed with flickering and static. See photos.
Given some pointers on where to start, I'm willing to build from source and test patches.
Workaround: Use vesa driver, get ugly interlaced mode.
Related: [Bug 54794](https://bugs.freedesktop.org/show_bug.cgi?id=54794)
**Attachment 67894**, "Monitor output":
![Monitor](/uploads/db1740eb9bc258225473ad3a5de63549/Monitor.jpg)
Version: 7.7 (2012.06)https://gitlab.freedesktop.org/xorg/driver/xf86-video-trident/-/issues/7trident + XVideo = corrupt output2018-08-10T20:48:26ZBugzilla Migration Usertrident + XVideo = corrupt output## Submitted by David Flater
Assigned to **Xorg Project Team**
**[Link to original bug (#54794)](https://bugs.freedesktop.org/show_bug.cgi?id=54794)**
## Description
Created attachment 67009
It's supposed to say "Xine" ...
Video ...## Submitted by David Flater
Assigned to **Xorg Project Team**
**[Link to original bug (#54794)](https://bugs.freedesktop.org/show_bug.cgi?id=54794)**
## Description
Created attachment 67009
It's supposed to say "Xine" ...
Video card: Trident 3DImàge985 4MB
Video mode: 1024x768, depth 16 or 24
x.org configuration (slackware-current as of 2012-09-09):
X.Org X Server 1.12.3
Release Date: 2012-07-09
[ 2740.985] (II) Module trident: vendor="X.Org Foundation"
[ 2740.985] compiled for 1.12.1, module version = 1.3.5
[ 2740.986] Module class: X.Org Video Driver
[ 2740.986] ABI class: X.Org Video Driver, version 12.0
Problem: With normal settings at depth 24, the video output of ffplay and
xine is messed up with a split double image in the window and horizontal
lines and garbage spilling over to the rest of the screen. See uploaded
photo.
At depth 16, the extraneous horizontal lines go away but the internal
contents of the window are still messed up.
Poor workaround: Adding the following to xorg.conf avoids the problem but
kills video performance.
Section "Module"
SubSection "extmod"
Option "omit XVideo"
EndSubSection
EndSection
Other information: The same problem occurred with the following older
configuration (Slackware 13.37):
X.Org X Server 1.9.5
Release Date: 2011-03-17
[ 40.449] (II) Module trident: vendor="X.Org Foundation"
[ 40.450] compiled for 1.9.2, module version = 1.3.4
[ 40.450] Module class: X.Org Video Driver
[ 40.450] ABI class: X.Org Video Driver, version 8.0
I have no data for any other versions.
**Attachment 67009**, "It's supposed to say "Xine" ...":
![xine](/uploads/f40e3a76f2b291a287d928dd6d8f9ddf/xine.jpg)
Version: 7.7 (2012.06)https://gitlab.freedesktop.org/xorg/driver/xf86-video-trident/-/issues/6NoDDC option doesn't work for trident cyberblade/i1 resulting in system lockup2018-08-10T20:48:22ZBugzilla Migration UserNoDDC option doesn't work for trident cyberblade/i1 resulting in system lockup## Submitted by Bryce Harrington `@bryce`
Assigned to **Xorg Project Team**
**[Link to original bug (#15937)](https://bugs.freedesktop.org/show_bug.cgi?id=15937)**
## Description
Forwarding report from Ubuntu: https://bugs.launch...## Submitted by Bryce Harrington `@bryce`
Assigned to **Xorg Project Team**
**[Link to original bug (#15937)](https://bugs.freedesktop.org/show_bug.cgi?id=15937)**
## Description
Forwarding report from Ubuntu: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-trident/+bug/223774
Sounds like trident needs autodetection added and/or needs DDC probing shut off to prevent lockups.
"it was possible get the display on a Toshiba Satellite 1800 working by editing the Device section of of /etc/X11/xorg.conf to have Option "NoDDC" "true". (vesa driver doesn't work either)
The display adaptor built into the laptop is a Trident CyberBlade/i1
It turns out that the right xorg.conf works (but not the autogenerated from Hardy, and for Gutsy it must be present before the install configures xserver-xorg or it'll hang during the configuration of that package), provided the NoDDC option is present.
http://launchpadlibrarian.net/14025687/Xorg.0.log.hardy
The xorg.conf I used in gutsy (and hardy when the default one failed) is derived one at from http://michaelminn.com/linux/toshiba1800/, the result of which looks like this:
# xorg.conf (X.Org X Window System server configuration file)
#
# Custom file by Michael Minn
Section "InputDevice"
Identifier "Generic Keyboard"
Driver "kbd"
Option "XkbRules" "xorg"
Option "XkbModel" "pc105"
Option "XkbLayout" "us"
EndSection
Section "InputDevice"
Identifier "Configured Mouse"
Driver "mouse"
Option "CorePointer"
Option "Device" "/dev/input/mice"
Option "Protocol" "ImPS/2"
EndSection
Section "Device"
Identifier "Trident Microsystems CyberBlade/i1"
Driver "trident"
BusID "PCI:1:0:0"
Option "NoDDC"
EndSection
Section "Monitor"
Identifier "ToshLCD"
Option "DPMS"
HorizSync 30-71
VertRefresh 50-100
EndSection
Section "Screen"
Identifier "Default Screen"
Monitor "ToshLCD"
Device "Trident Microsystems CyberBlade/i1"
DefaultDepth 24
SubSection "Display"
Depth 16
Modes "1024x768" "800x600"
EndSubSection
SubSection "Display"
Depth 24
Modes "1024x768" "800x600"
EndSubSection
EndSection
Section "ServerLayout"
Identifier "Default Layout"
Screen "Default Screen"
InputDevice "Configured Mouse"
EndSection
Version: 7.3 (2007.09)https://gitlab.freedesktop.org/xorg/driver/xf86-video-trident/-/issues/5TV-out on Cyberblade/i1 (Epia 800): Only black screen2018-08-10T20:48:20ZBugzilla Migration UserTV-out on Cyberblade/i1 (Epia 800): Only black screen## Submitted by Jacob Barsøe Kjærgaard
Assigned to **Xorg Project Team**
**[Link to original bug (#14555)](https://bugs.freedesktop.org/show_bug.cgi?id=14555)**
## Description
Hi,
I have a trident cyberblade/i1 rev6a. However, th...## Submitted by Jacob Barsøe Kjærgaard
Assigned to **Xorg Project Team**
**[Link to original bug (#14555)](https://bugs.freedesktop.org/show_bug.cgi?id=14555)**
## Description
Hi,
I have a trident cyberblade/i1 rev6a. However, the tv-out does not work.
It does not work in either NTSC or PAL mode.I use the VT1621 chip.
If I use the chrontel chip setting in my xorg.conf I manage to get a picture, but the picture starts at a different pixel every time I restart X.
Using the VT1621 chip (which I guess is supposed to be the right choice for my chipset) the TV switches to black screen. It does switch though, but I cannot get back from the black screen. X is running perfectly in the background.
I have had tv-out working for a long time, but when migrating from xfree86 to xorg problems occured; first X started in black/white, however that could be circumvented by calling mplayer which on playback made the screen turn into colors, but later on, after I updated (gentoo update that is) in April last year the tv-out has gone all black.
I really hope you can help me out here - I don't want to transfer my HTPC into a windows machine:)
Regards,
Jacob
xorg version 7.3, xorg-server 1.4.0.90-r3 (gentoo).
trident-driver version 1.2.3
xorg.conf:
Section "Device"
Identifier "trident driver"
Driver "trident"
# Option "TVChipSet" "CH7005"
Option "TVChipSet" "VT1621"
# Option "TVSignal" "1"
Option "TVSignal" "0"
EndSection
xorg.log output: (grepped with TRIDENT)
(II) TRIDENT: driver for Trident chipsets: tvga9000, tvga9000i, tvga8900c,
(**) TRIDENT(0): Depth 16, (--) framebuffer bpp 16
(II) TRIDENT(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
(==) TRIDENT(0): RGB weight 565
(==) TRIDENT(0): Default visual is TrueColor
(==) TRIDENT(0): Using gamma correction (1.0, 1.0, 1.0)
(**) TRIDENT(0): Option "TVChipset" "VT1621"
(**) TRIDENT(0): Option "TVSignal" "0"
(==) TRIDENT(0): Using XAA for acceleration
(**) TRIDENT(0): Using VIA VT1621 TV chip
(==) TRIDENT(0): Linear framebuffer at 0xD9800000
(--) TRIDENT(0): IO registers at 0xDA000000
(II) TRIDENT(0): initializing int10
(II) TRIDENT(0): Primary V_BIOS segment is: 0xc000
(II) TRIDENT(0): VESA BIOS detected
(II) TRIDENT(0): VESA VBE Version 2.0
(II) TRIDENT(0): VESA VBE Total Mem: 8192 kB
(II) TRIDENT(0): VESA VBE OEM: Copyright 1998 TRIDENT MICROSYSTEMS INC.
(II) TRIDENT(0): VESA VBE OEM Software Rev: 0.0
(II) TRIDENT(0): VESA VBE OEM Vendor:
(II) TRIDENT(0): VESA VBE OEM Product:
(II) TRIDENT(0): VESA VBE OEM Product Rev:
(II) TRIDENT(0): VESA VBE DDC supported
(II) TRIDENT(0): VESA VBE DDC Level 1 + 2
(II) TRIDENT(0): VESA VBE DDC transfer in appr. 1 sec.
(II) TRIDENT(0): VESA VBE DDC read failed
(--) TRIDENT(0): Revision is 106
(--) TRIDENT(0): Found CyberBlade/i1 chip
(--) TRIDENT(0): RAM type is SDRAM
(--) TRIDENT(0): Using SW cursor
(--) TRIDENT(0): VideoRAM: 8192 kByte
(--) TRIDENT(0): TFT Panel 800x600 found
(--) TRIDENT(0): Memory Clock is 57.27 MHz
(==) TRIDENT(0): Min pixel clock is 12 MHz
(--) TRIDENT(0): Max pixel clock is 230 MHz
(II) TRIDENT(0): My Monitor: Using hsync range of 31.50-35.10 kHz
(II) TRIDENT(0): My Monitor: Using vrefresh range of 50.00-70.00 Hz
(II) TRIDENT(0): Clock range: 12.00 to 230.00 MHz
(II) TRIDENT(0): Not using default mode "640x350" (hsync out of range)
(II) TRIDENT(0): Not using default mode "320x175" (bad mode ...
snipped all those "not using default mode"
(--) TRIDENT(0): Virtual size is 800x600 (pitch 800)
(**) TRIDENT(0): *Default mode "800x600": 36.0 MHz, 35.2 kHz, 56.2 Hz
(II) TRIDENT(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 6
25 +hsync +vsync (35.2 kHz)
(**) TRIDENT(0): *Default mode "640x480": 25.2 MHz, 31.5 kHz, 59.9 Hz
(II) TRIDENT(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 52
5 -hsync -vsync (31.5 kHz)
(==) TRIDENT(0): DPI set to (75, 75)
(II) TRIDENT(0): Initializing int10
(II) TRIDENT(0): Primary V_BIOS segment is: 0xc000
(II) TRIDENT(0): Overriding Horizontal timings.
(II) TRIDENT(0): Shadow off
(II) TRIDENT(0): H-timing shadow registers: 0x7f 0x00 0x69 0x7f
(II) TRIDENT(0): H-timing registers: 0x7b 0x63 0x63 0x80 0x67 0x10
(II) TRIDENT(0): V-timing shadow registers: 0x72 0xf0 0x59 0x0d 0x00 (0
x08)
(II) TRIDENT(0): V-timing registers: 0x6f 0xf0 0x59 0x2b 0x57 0x00 0x00
(II) TRIDENT(0): Setting BIOS Mode: 77 for: 800x600
(II) TRIDENT(0): Found Clock 36.00 n=163 m=15 k=2
(II) TRIDENT(0): Using 1447 scanlines of offscreen memory for area's
(II) TRIDENT(0): Using 5113408 bytes of offscreen memory for linear (offset=0x31f
9c0)
(II) TRIDENT(0): Using XFree86 Acceleration Architecture (XAA)
(==) TRIDENT(0): Backing store disabled
(II) TRIDENT(0): Trident Video Flags: VID_ZOOM_INV VID_ZOOM_MINI
Version: 7.3 (2007.09)https://gitlab.freedesktop.org/xorg/driver/xf86-video-trident/-/issues/4Segfault when scrolling2018-08-10T20:48:17ZBugzilla Migration UserSegfault when scrolling## Submitted by Al Dimond
Assigned to **Xorg Project Team**
**[Link to original bug (#6625)](https://bugs.freedesktop.org/show_bug.cgi?id=6625)**
## Description
I have been getting fairly regular segfaults with xorg 6.9.0 under Fr...## Submitted by Al Dimond
Assigned to **Xorg Project Team**
**[Link to original bug (#6625)](https://bugs.freedesktop.org/show_bug.cgi?id=6625)**
## Description
I have been getting fairly regular segfaults with xorg 6.9.0 under FreeBSD
6-stable, using the Trident driver. Usually they occur when I'm dragging a
program's scroll bars; it happens especially when the program is being run
through ssh/X-tunneling, but has also occurred when using Firefox and Opera locally.
The log file doesn't tell me anything more than that the server received signal
11; I logged in remotely and got a backtrace using GDB, and here's where it gets
strange: the binaries I'm using right now don't appear to have debugging symbols
in them so I don't know exactly where this is but the backtrace is 1676 deep,
which caught my attention. Here is an excerpt:
```
Program received signal SIGSEGV, Segmentation fault.
0x2825b1b1 in ?? ()
(gdb) bt
#0 0x2825b1b1 in ?? ()
#1 0x00000000 in ?? ()
#2 0x00000000 in ?? ()
#3 0x08fb5a30 in ?? ()
#4 0x08fb5a30 in ?? ()
#5 0x00000000 in ?? ()
#6 0x08fb5000 in ?? ()
#7 0x00000008 in ?? ()
#8 0x00000005 in ?? ()
#9 0x00000010 in ?? ()
#10 0x00000000 in ?? ()
#11 0x00000000 in ?? ()
#12 0x282c44e4 in ?? ()
#13 0x081b0488 in ?? ()
#14 0x08fb5a30 in ?? ()
#15 0xbfbfe6b8 in ?? ()
#16 0x2825ba41 in ?? ()
#17 0x00000000 in ?? ()
#18 0x00000000 in ?? ()
#19 0x00000000 in ?? ()
#20 0x02fc0000 in ?? ()
#21 0x00000000 in ?? ()
#22 0x00000000 in ?? ()
#23 0x00000000 in ?? ()
---Type <return> to continue, or q <return> to quit---
#24 0x00000000 in ?? ()
#25 0x00000000 in ?? ()
#26 0x00000000 in ?? ()
#27 0x00000000 in ?? ()
#28 0x00000000 in ?? ()
#29 0xbfbfe700 in ?? ()
#30 0x082d79c0 in ?? ()
#31 0xbfbfe668 in ?? ()
#32 0x0817cc5d in ?? ()
#33 0xbfbfe700 in ?? ()
#34 0x081c5cb0 in ?? ()
#35 0xbfbfe678 in ?? ()
#36 0x081af3a8 in ?? ()
#37 0x08220258 in ?? ()
#38 0x2879bff8 in ?? ()
#39 0xbfbfe698 in ?? ()
#40 0x286a3b25 in ?? ()
#41 0x00000003 in ?? ()
#42 0xbfbfe700 in ?? ()
```
...
```
#1649 0x102454ff in ?? ()
#1650 0x2024448d in ?? ()
#1651 0x5440f750 in ?? ()
#1652 0x00020000 in ?? ()
#1653 0x688e0375 in ?? ()
#1654 0x01a1b814 in ?? ()
#1655 0xcd500000 in ?? ()
---Type <return> to continue, or q <return> to quit---
#1656 0x90feeb80 in ?? ()
#1657 0x102454ff in ?? ()
#1658 0x1424448d in ?? ()
#1659 0x5440f750 in ?? ()
#1660 0x00020000 in ?? ()
#1661 0x688e0375 in ?? ()
#1662 0x0158b814 in ?? ()
#1663 0xcd500000 in ?? ()
#1664 0x90feeb80 in ?? ()
#1665 0x102454ff in ?? ()
#1666 0x1424448d in ?? ()
#1667 0x1840f750 in ?? ()
#1668 0x00020000 in ?? ()
#1669 0x688e0375 in ?? ()
#1670 0x0067b844 in ?? ()
#1671 0xcd500000 in ?? ()
#1672 0x90feeb80 in ?? ()
#1673 0xbfbfecb0 in ?? ()
#1674 0x00000004 in ?? ()
#1675 0xbfbfecc4 in ?? ()
#1676 0x00000013 in ?? ()
Error accessing memory address 0xbfc00000: Bad address.
(gdb)
```
All addresses from #624 through #1648 are 0x00000000, if that helps.
I don't really *want* to recompile X with debugging symbols, because the
computer in question is a crummy old laptop with overheating issues, but I'm
considering it. I haven't found any similar bugs in bugzilla in my searches so
far; if I can glean any more info out of my system I'll post it back here.
Version: 6.9.0https://gitlab.freedesktop.org/xorg/driver/xf86-video-trident/-/issues/3overlay misalignment and "garbage" line on CyberBladeXP2018-08-10T20:48:14ZBugzilla Migration Useroverlay misalignment and "garbage" line on CyberBladeXP## Submitted by Philip Pemberton
Assigned to **Alan Hourihane**
**[Link to original bug (#5428)](https://bugs.freedesktop.org/show_bug.cgi?id=5428)**
## Description
System: Toshiba Satellite Pro 4600. 700MHz Coppermine Celeron, 25...## Submitted by Philip Pemberton
Assigned to **Alan Hourihane**
**[Link to original bug (#5428)](https://bugs.freedesktop.org/show_bug.cgi?id=5428)**
## Description
System: Toshiba Satellite Pro 4600. 700MHz Coppermine Celeron, 256MB RAM.
Trident CyberBladeXP chipset with 14" 1024x768 LCD.
OS: Fedora Core 4 i386 with latest updates (from "yum update") as of 2005-12-25
Xorg version:
When I play any video file in any application that uses Xv (Xvideo?) to output
video, a blue border (width varies dependent on screen BPP - two pixels for
16-bit, 3 pixels for 24-bit) is visible along the left hand side of the image,
and a single-pixel wide green line (colour varies and the line often has garbage
inside it) is visible along the bottom.
When the left-hand border is corrected (using the XvHsync and XvRskew Options),
it becomes apparent that two pixels from the LHS of the video have been moved
over to the RHS. They maintain the same pixel order, but are displaced one pixel
vertically upwards. It's always two pixels that get moved - the display BPP
setting does not affect it.
The "garbage line" along the bottom of the screen is not affected by setting
XvBskew to 1. It also only seems to appear in full-screen mode; the same colour
appears in the two pixels on the bottom row of the block that gets moved from
the left.
The Videolan "VLC" video player is very good at provoking these symptoms, it
seems, especially in Full Screen mode...
I would provide screenshots, but I have yet to find a method to capture decent
quality ones that include the overlay video. I will upload my xorg.conf and Xorg
startup log as soon as I fish them off the laptop's HDD.
Version: 6.8.2https://gitlab.freedesktop.org/xorg/driver/xf86-video-trident/-/issues/2CyberBlade/xp4 Glowing White Screen modify xorg.conf to "vesa"2018-08-10T20:48:07ZBugzilla Migration UserCyberBlade/xp4 Glowing White Screen modify xorg.conf to "vesa"## Submitted by Ben Kevan
Assigned to **Alan Hourihane**
**[Link to original bug (#5215)](https://bugs.freedesktop.org/show_bug.cgi?id=5215)**
## Description
I have a Toshiba Tecra M1 and when X tries to load it becomes white and ...## Submitted by Ben Kevan
Assigned to **Alan Hourihane**
**[Link to original bug (#5215)](https://bugs.freedesktop.org/show_bug.cgi?id=5215)**
## Description
I have a Toshiba Tecra M1 and when X tries to load it becomes white and never
loads. Here is copy of the original device section xorg.conf
Section "Device"
BoardName "CyberBlade/xp4"
BusID "1:0:0"
Driver "trident"
Identifier "Device[0]"
Screen 0
VendorName "Trident"
EndSection
Once I modified it to:
Section "Device"
BoardName "CyberBlade/xp4"
BusID "1:0:0"
Driver "vesa"
Identifier "Device[0]"
Screen 0
VendorName "Trident"
EndSection
It would load and I can use the machine, just thought I would show you guys. Is
this fixed in a later version? How can I install a newer version? Thanks.
Version: 6.8.2https://gitlab.freedesktop.org/xorg/driver/xf86-video-trident/-/issues/1cyber9320 on the Thinkpad 365X[D] DSTN - "orange lines" and system crash/freeze2018-08-10T20:48:04ZBugzilla Migration Usercyber9320 on the Thinkpad 365X[D] DSTN - "orange lines" and system crash/freeze## Submitted by James
Assigned to **Egbert Eich**
**[Link to original bug (#2323)](https://bugs.freedesktop.org/show_bug.cgi?id=2323)**
## Description
The XFree86 trident driver has always had a problem with the Thinkpad 365XD Tri...## Submitted by James
Assigned to **Egbert Eich**
**[Link to original bug (#2323)](https://bugs.freedesktop.org/show_bug.cgi?id=2323)**
## Description
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.
Version: 6.8.1