From owner-freebsd-multimedia Sun Sep 14 15:29:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA06386 for multimedia-outgoing; Sun, 14 Sep 1997 15:29:10 -0700 (PDT) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA06371 for ; Sun, 14 Sep 1997 15:29:00 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Sun, 14 Sep 1997 18:28:23 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA28377; Sun, 14 Sep 97 18:28:22 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id SAA09100; Sun, 14 Sep 1997 18:24:54 -0400 Message-Id: <19970914182453.20720@ct.picker.com> Date: Sun, 14 Sep 1997 18:24:53 -0400 From: Randall Hopper To: Andrew Gordon Cc: multimedia@FreeBSD.ORG Subject: Re: fxtv problems with Matrox Millenium References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: ; from Andrew Gordon on Fri, Jun 20, 1997 at 03:55:01PM +0100 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Man, this is from June 20 and here it is mid-September. I'm not sure how I missed replying to this message in my multimedia folder earlier. Sorry about that. I'm trying to get it back under control again now that I've got some time. I don't have access to a PAL board and signal so I can't do much more than offer debugging suggestions and solicit fixes from the folks is Europe. Any and all input welcome. Just send me a patch against the latest version and consider it "in" for the next version. Andrew Gordon: |I have been using fxtv for a few weeks now, initially with the following |configuration: | | Hauppauge Win/TVpci (UK PAL version), Matrox Millenium (4Mb), P6 ... |- Fitted 8Mb RAM upgrade to the Matrox card, leaving Xfree86 configuration | unchanged for the time being (ie. no change to mode lines etc.) | Everything else still OK, but the video image appears in the wrong place! | |The video image seems to be displaced by a constant number of pixels to |the left of where it should be; with the initial (small) window, only |about the right-hand 20% of the image is actually inside the fxtv window, |but with a larger window the strip outside the window remains the same |width and correspondingly more of the image inside the window. |Vertical position remains correct. First, is this still a problem for you, or have some driver fixes been put in-place that by chance have cleared this up. The fact that the image appears solid and the picture itself looks OK (I assume since you didn't mention it) and that the vertical positioning is correct implies Fxtv knows the right pixel geometry, and frame buffer pitch. Aside from the base address of the frame buffer returned from the DGA extension, and the X and Y position of the fxtv window relative to the root window (from the X server as well), this is all that's involved in getting the upper-right corner of the video set correctly for direct video with the driver. I don't know what to suggest. Sounds like it might be something that needs smoothed over in the driver, if this is still a problem. See if adding -disableDirectV produces correct results. | - Clicking the 'expand/contract' icon on the toolbar when the window is | near the bottom right hand corner of the screen always puts part of | the image off-screen (with consequent bleep and error messages). | I presume this is logic somewhere not taking account of the | different size of the PAL/50Hz picture. The beep and error message is fxtv doing a last minute sanity-check on the direct video region to make sure that it's entirely on the frame buffer (. If any of the transfer area would be off of the frame buffer, (since clipping isn't in there yet) it aborts the request to start capture. This one is puzzling too. tvscreen.c::TVSCREENSetZoomState is where this Zoom behavior is implemented. On a zoom, the window is set to max size: g.w = c->width_max; g.h = c->height_max; and then the window is shifted up and left if necessary so that it lies entirely on the display (if possible). For PAL ("Fxtv.inputFormat: pal" or "-inputFormat pal"), width_max = 768 and height_max = 576. Since this works fine for NTSC, I'm inclined to think that DGA might not be returning the correct values for your video card. You might put some printfs around this condition in tvcapture.c::TVCAPTUREConfigure: else if ( addr + ( (g.h-1) * x->pitch + g.w ) * Bpp >= x->base_addr + x->bank_size ) { strcpy( S_err_msg, "Direct video region outside bounds of display" ); goto RETURN; } and see if it's this condition that's firing. If so, print out these values and see what they are when you maximize by the edge of the display again. | - Overlapping windows disable the image completely when in direct video | mode. I presume this is simply not implemented - or is it specific | to the Matrox? Yep, Amancio's got clipping code in the driver, but support hasn't been added to Fxtv for it yet. For now, sinc you've got a P6 you may want to run with direct video disabled and let the X server do the clipping for you; that may be more CPU than you're willing to dedicate though. Randall Hopper