Bug 2528 - xv overlay shows blue window on a Trident Cyber-XP4
Summary: xv overlay shows blue window on a Trident Cyber-XP4
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Trident (show other bugs)
Version: 6.7.0
Hardware: x86 (IA32) All
: high normal
Assignee: Alan Hourihane
QA Contact: Xorg Project Team
: 7842 8549 9636 (view as bug list)
Depends on:
Reported: 2005-02-12 07:40 UTC by ZC Wong
Modified: 2008-02-10 13:13 UTC (History)
6 users (show)

See Also:
i915 platform:
i915 features:

Don't set VID_DOUBLE_LINEBUFFER_FOR_WIDE_SRC for XP4 (443 bytes, patch)
2008-01-07 12:35 UTC, Konrad Rzepecki
no flags Details | Splinter Review

Description ZC Wong 2005-02-12 07:40:22 UTC
xvinfo shows it support this card but the content of the window is constantly
blue when I try to play video files using mplayer(It works if I select other
output interfaces).
Comment 1 Guy Martin 2005-11-30 01:42:52 UTC
#2785 Seems to fix this issue. 

Did you tried the patch attached to that bug ?
Comment 2 Kirill Smelkov 2005-12-10 00:29:21 UTC
I fought the very like problem, hence I'll post here.   
Problem1. V4L does not use Trident Backend Scaler.   
          This results in inability to resize PAL video larger than 768x576   
          (PAL native size) pixels.   
          [solved -- see below]   
Problem2. Event when V4L uses the scaler, I get blue screen when trying to    
          watch video using xawtv/Xv  on *high resolutions*. low & mid    
          resolutions are ok.   
          [partly solved -- see below]   
[I'll propose my solution to the problems in the end of this message]   
My setup:   
1. ICV100 video capture (bttv based)   
2. Trident Cyberblade/i1:   
   VGA compatible controller: Trident Microsystems CyberBlade/i1 (rev 6a)   
3. xawtv -hwscan:   
This is xawtv-3.94, running on Linux/i686 (   
looking for available devices   
port 53-53                              [ -xvport 53 ]   
    type : Xvideo, video overlay   
    name : video4linux   
port 54-54   
    type : Xvideo, image scaler   
    name : Trident Backend Scaler   
/dev/video0: OK                         [ -device /dev/video0 ]   
    type : v4l2   
    name : BT878 video (IVC-100)   
    flags: overlay capture     
Problem1. V4L does not use Trident Backend Scaler.   
Although the scaler supports the format V4L wants (YUY2):   
#1 see xc/programs/Xserver/hw/xfree86/drivers/v4l:v4l_check_yuv   
#2 xvinfo (only relevant output left)   
  Adaptor #1: "Trident Backend Scaler"   
      id: 0x32595559 (YUY2)   
        guid: 59555932-0000-0010-8000-00aa00389b71   
        bits per pixel: 16   
        number of planes: 1   
        type: YUV (packed)   
Internally it tells V4L, it supports (rgb based) RV16.   
line  189   
line 1125   
The solution is to expose YUY2 format as supported by scaler:   
Index: xc/programs/Xserver/hw/xfree86/drivers/trident/trident_video.c   
--- xc.orig/programs/Xserver/hw/xfree86/drivers/trident/trident_video.c   
2005-12-09 15:50:01.000000000 +0300   
+++ xc/programs/Xserver/hw/xfree86/drivers/trident/trident_video.c 2005-12-09   
15:50:14.000000000 +0300   
@@ -1166,7 +1166,7 @@   
     if(!(offscreenImages = xalloc(sizeof(XF86OffscreenImageRec))))   
-    offscreenImages[0].image = &Images[0];   
+    offscreenImages[0].image = &Images[2];  /* XVIMAGE_YUY2 */   
     offscreenImages[0].flags = VIDEO_OVERLAID_IMAGES |    
     offscreenImages[0].alloc_surface = TRIDENTAllocateSurface;   
With this change, V4L uses backend scaler, and i can resize the video up to   
fullscreen. tested on 1280x1024 resolution.   
Problem2. When i try to use 1600x1200 resolution (mine LCD native res.) I get   
only blue box instead of video.   
I could not figure out what is the real problem, but it appeared that the   
problem can be avoided when *non standard* timings are used (sick!)  
standard timings (blue box): 
Modeline "1600x1200"  162.00  1600 1664 1856 2160  1200 1201 1204 1250 +hsync 
nonstd timings   (video=ok):  
Modeline "ZZZ"  162.00  1600 1762 1828 2044  1200 1201 1204 1250 +hsync +vsync  
The question is: how timing difference affects the scaler? what is the proper 
fix for my problem? 
Comment 3 Alan Hourihane 2006-10-02 01:27:18 UTC
*** Bug 7842 has been marked as a duplicate of this bug. ***
Comment 4 Alan Hourihane 2006-12-01 02:59:55 UTC
*** Bug 8549 has been marked as a duplicate of this bug. ***
Comment 5 Daniel Stone 2007-02-27 01:25:23 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 6 Konrad Rzepecki 2007-10-14 15:21:14 UTC
I have this same problem.

I try to debug it, but almost unsucessful.

I wrote simple program to read VGA registers when xvtest program is running. I found that values written to 0x91 CRT register disappear (hi byte of numer of bytes in a row). Is this normal? 0x90 CRT register (lo byte) values seems to be keeped.

When I wrote fixed value 0xFF to 0x90 CRT and decrease hsync by 256 (0x86 & 0x87 CRT), I have some blinking artefacts moving together with xvtest window.

Can you give me a hint, what I should check more?

PS. All CRT value change I made in TRIDENTDisplayVideo function.
PS2. I use hint above, and change default offscreen images to YUY2 but i made this by changing order of Images array (YUY2,YV12,RV16) - is this revelant? 
Comment 7 Konrad Rzepecki 2007-10-23 12:18:02 UTC
I'm little close to solve this but I NEED YOUR HELP what to do further.

When I set 0x57 sequencer register (key mode function), from 0xC0 (color key & playback key) to 0xCC (playback key only), overlay image appear. But since there is no color key, it is always on top. So this is probably color key problem.

Additionaly when I display overlay I see two other problems:

1. XvHsync must be set to "-25" - easy to fix with new case in code;

2. Scaling dimesions are not perfect, they are appear strange frames on the right and bottom of image (see here: http://www.astral.lodz.pl/~hannibal/xvtest.jpg [1.4MB]). They width/height change periodically during window resize.
Comment 8 Jan Darmochwal 2008-01-06 08:01:58 UTC
You have to enable the color key for this card. I found the hint in the documentation for the XGI 8300/XP10 (bug 5921).

--- trident_video.c     2008-01-06 16:17:32.000000000 +0100
+++ trident_video.c     2008-01-06 16:31:18.000000000 +0100
@@ -261,6 +261,9 @@ void TRIDENTResetVideo(ScrnInfoPtr pScrn
        OUTW(0x3C4, 0x007A);
        OUTW(0x3C4, 0x007D);
+    if (pTrident->Chipset == CYBERBLADEXP4) {
+        OUTW(0x3CE, 0x0462); /* enable color key */
+    }
     switch (pScrn->depth) {
     case 8:
        VIDEOOUT(pPriv->colorKey, pTrident->keyOffset);
@@ -1277,6 +1280,10 @@ tridentFixFrame(ScrnInfoPtr pScrn, int *
            pTrident->hsync -= 15;
            pTrident->hsync_rskew = 3;
+        case CYBERBLADEXP4:
+            pTrident->hsync -= 24;
+            pTrident->hsync_rskew = -1;
+            break;
        case BLADE3D:
            if (pScrn->depth == 24)
                pTrident->hsync -= 8;
Comment 9 Alan Hourihane 2008-01-06 12:27:10 UTC
Thanks for the patch. Committed.

Let me know if the others get this working now and I can close this bug and make a new release.
Comment 10 Alan Hourihane 2008-01-06 12:28:53 UTC
*** Bug 9636 has been marked as a duplicate of this bug. ***
Comment 11 Konrad Rzepecki 2008-01-07 08:11:57 UTC
It works for me. But since fix is taken from XP10 datasheet more logical fix not only for XP4 boards but all newer XP. So, I think, "if" should look like this: "if (pTrident->Chipset >= CYBERBLADEXP4) {".

Jan - thanks for the patch.
Comment 12 Konrad Rzepecki 2008-01-07 12:35:29 UTC
Created attachment 13576 [details] [review]

I'm little to fast. I have encounter problem which Kirill has. Little overlays are ok but bigger are not (data are displayed - but they are garbage [vertical stripes]). But I have sucessful debug it. XP4 shouldny have set flag VID_DOUBLE_LINEBUFFER_FOR_WIDE_SRC.

The attached patch remove it for XP4 and never boards. Maybe this apply to older ones (Kirill has i1).
Comment 13 Kostas Georgiou 2008-01-19 17:13:31 UTC
With the latest patch applied xv now works great on a portege r100 (XP4m32).
Comment 14 Tomas Halvarsson 2008-02-10 02:31:46 UTC
With the patches by Jan Darmochwal (2008-01-06) and Konrad Rzepecki (2008-01-07), "mplayer -vo xv movie.mpeg" now works both in a window and full-screen on a Toshiba Portege R100 (XP4m32). A new release would be appreciated.
Comment 15 Alan Hourihane 2008-02-10 13:13:50 UTC
Fixed. Thanks for the patch.

Just tagged version 1.2.4, but I'll upload the tarball later.

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.