When using Xorg on a Trident CyberBlade/i1 with a TV encoder (VT1621 (both NTSC and PAL), Xorg fails to use a working TV display. Here's the setup: Epia 800 (lspci output attached) FC2 (Xorg 6.7 (version output attached)) Samsung Plano TV Before going further about the bug, I want to first thank you for the work you guys have done for this driver and Xorg in general. It's fine and I want to help make it better. Now, the Epia BIOS and jumpers are configured to output PAL. So console mode works fine with the TV. Meaning, until I start Xorg, I can succesfully use the TV and the display works fine with all the normal console stuff. Once I start Xorg, (i've appended the various xorg.conf's that i've tried), the display goes swizzly (noise) for a few seconds and then blue screens indicating that the TV doesn't like the input. But Xorg is active and believes that it has successfully controlled the display (according to Xorg.0.log). I then tried a patched trident driver from Alastair Robinson at black5services. This also failed to get the TV display on init, but when combined with TVtool (run from the shell to set the tv output manually) (also from Alastair), I was able to get a working TV output at 640x480 (log files attached). I was then able to use most applications cleanly. However, mplayer playing content in xvidix mode exhibited a narrow noisy band on the right hand side of the TV (likely related to bug 431). I'd be happy to help debug the issue. I will set up a Xorg build so that I can build the trident driver and test any changes. But I'm not too knowledgable about the driver details so I will likely need advice and directions. Here's what I'd like to solve with respect to this bug: 1. Get Xorg to succesfully use the tv output (merging back the changes from black5's code and removing the need for tvtool?) 1a. Get Xorg -configure to generate the correct config for TV output if TV output is selected 2. Support mplayer XVIDIX correctly. Currently, using the black5 driver, I get a noisy band at the right hand side of the TV. This noisy band looks very much like it's coming from what should be a narrow band on the left hand side of the screen. Perhaps this is related to bug 431 filed by Richard Pinnell about this same driver. Okay. I really hope that you guys might be available to help direct me towards fixing this. I'm happy to spend time on this. Thanks, Melkor
Created attachment 349 [details] lspci output
Created attachment 350 [details] lspci verbose output
Created attachment 351 [details] xorg.conf generated using xorg -configure and updated with tvsignal and default depth set
Created attachment 352 [details] Xorg.0.log from using xorg.conf where tv chipset option was set
Created attachment 353 [details] xorg.conf from xorg -configure after modifying to set tv chipset and tv screen
Created attachment 354 [details] xorg.0.log when using black5's moded trident driver instead of the 6.7 trident driver
You should set "TVSignalMode" to "1" to set PAL.
I have the same problem here (same hardware, same setup). In console-mode TV out works nicely but in X there is either noise or a black screen. It did work around XFree86 4.2.0 or so (with the BlackFive driver). I have tried variations of the following device settings: Section "Device" Identifier "Trident" Driver "trident" Option "HWCursor" "on" Option "PciRetry" "true" Option "TVChipset" "VT1621" Option "TVSignal" "1" Option "TVSignalMode" "1" # Option "NoPciBurst" "on" EndSection If I enable the TV-Out settings the startup of X takes slightly longer so the driver seems to atleast try do something. There may be something else I have missed in the configuration file but these are the only options I could find documented in the man file. The X.org version is from RH Fedora core development: 6.7.0-4
This bug still exists in 6.9.0.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Do you still have hardware to test this? Is it still an issue?
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.