Bug 2528

#2785 Seems to fix this issue. 

Did you tried the patch attached to that bug ?

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 (2.6.14.3--NAVY)   
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.   
see   
http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/drivers/trident/trident_video.c?annotate=1.6   
   
line  189   
line 1125   
   
[solution-1]   
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))))   
        return;   
    
-    offscreenImages[0].image = &Images[0];   
+    offscreenImages[0].image = &Images[2];  /* XVIMAGE_YUY2 */   
     offscreenImages[0].flags = VIDEO_OVERLAID_IMAGES |    
                               VIDEO_CLIP_TO_VIEWPORT;   
     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!)  
  
details: 
standard timings (blue box): 
Modeline "1600x1200"  162.00  1600 1664 1856 2160  1200 1201 1204 1250 +hsync 
vsync 
 
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? 
 
-- 
    Kirill. 

*** Bug 7842 has been marked as a duplicate of this bug. ***

*** Bug 8549 has been marked as a duplicate of this bug. ***

Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.

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? 

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.

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;
            break;
+        case CYBERBLADEXP4:
+            pTrident->hsync -= 24;
+            pTrident->hsync_rskew = -1;
+            break;
        case BLADE3D:
            if (pScrn->depth == 24)
                pTrident->hsync -= 8;

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.

*** Bug 9636 has been marked as a duplicate of this bug. ***

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.

Created attachment 13576 [details] [review]
Don't set VID_DOUBLE_LINEBUFFER_FOR_WIDE_SRC for XP4

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).

With the latest patch applied xv now works great on a portege r100 (XP4m32).

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.

Fixed. Thanks for the patch.

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