Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 14 Sep 1997 18:24:53 -0400
From:      Randall Hopper <rhh@ct.picker.com>
To:        Andrew Gordon <arg@arg1.demon.co.uk>
Cc:        multimedia@FreeBSD.ORG
Subject:   Re: fxtv problems with Matrox Millenium
Message-ID:  <19970914182453.20720@ct.picker.com>
In-Reply-To: <Pine.BSF.3.91.970620155044.19840A-100000@server.arg.sj.co.uk>; from Andrew Gordon on Fri, Jun 20, 1997 at 03:55:01PM %2B0100
References:  <Pine.BSF.3.91.970620155044.19840A-100000@server.arg.sj.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
     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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970914182453.20720>