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