Date: Tue, 19 May 1998 19:08:06 -0400 From: Randall Hopper <rhh@ct.picker.com> To: Igor Nikolaev <igor@pu.ru>, multimedia@FreeBSD.ORG, tomppa@fidata.fi, Amancio Hasty <hasty@rah.star-gate.com> Cc: freebsd-multimedia@FreeBSD.ORG Subject: Re: fxtv and milenniumIIagp Message-ID: <19980519190806.B4820@ct.picker.com> In-Reply-To: <19980518231539.40105@pu.ru>; from Igor Nikolaev on Mon, May 18, 1998 at 11:15:39PM %2B0400 References: <19980518231539.40105@pu.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Igor Nikolaev: |I have fxtv Version 0.46 and (working) milennium II AGP (Xfree 3.3.2). |My videocard works in 32bpp mode (in 16bpp all o'k) ... |When I have started fxtv I see next picture: ...<< tv data shifted to the left of the Fxtv window >>... | |Screen capture available on |ftp://hi.pu.ru/pub/fxtv.gif Good to see ya, and thanks for the pic. :-) This is the first time I've actually "seen" the problem. And I think I see some new information here that hasn't come to light before: REGION SIZE OFFSET ------------------ ------- ------ FXTV WINDOW: 777,322 - 1417,801 => 640x480 VIDEO BLOCK: 137,322 - 747,801 => 610x480 640,0 <-- Hmmm... ^^^ <---- Hmmmmmm... All right! Now where did those 30 pixels go :-) Also it's interesting that the offset is such a nice round number. Now look over on the far right side of your desktop, shifted up 238 scan lines. There's a sliver of video 433 pixels tall blasted over there. A few things I note. It's a bit interesting that the top lines of that sliver match up exactly with the top of your image window border. It's also interesting that bright area at the bottom has the same pixel values as the bright area on your shirt, and also that the height of that sliver is 433, not 480. |This is well know bug or unknown feature? It's a known bug, but the fix hasn't been found. As Tomi mentioned, he sees something similar on his Millennium II 8M (Matrox MGA 2164W) in 32bpp only like you. However, his image is shifted left 256 pixels (1024 bytes), not 640 pixels (2560 bytes) like yours. This is likely related to target frame buffer geometry and video mode as Tomi and Michael Petry saw their 256 shift at 1280x1024 but no shift at 1024x768. So looks like: Depth Desktop Size Video Mode Shift (pixels) ----- ------------ ---------- -------------- 32 1024x768 1024x768 ==> 0 pixels (cool) 32 1280x1024 1280x1024 ==> 256 pixels (not cool) 32 1600x1200 1600x1200 (?) ==> 640 pixels (not cool) >From Tomi's and Michael Petry's investigations on their Millenium/Millenium IIs (both 8Meg like yours BTW), it sounds to me like this is a bug in XFree's DGA support for some Milleniums & Millenium IIs in 32bpp. The base address of the frame buffer just doesn't seem to be where XFree says it is for some resolutions. And based on what I see in your pic, there's some weirdness with pixels in each scan line getting tossed or lost somewhere. XFree DGA bug? Some odd Matrox videomem organization? You got me. =================== Here are a few things to play with to help you and other Millenium folks flush out the behavior details for a bug report (probably to XFree86): (1) Try "fxtv -xrm 'Fxtv.Bpp32bit: 4'". See if you don't see the same erroneous behavior. (2) Running fxtv as above (1), move the fxtv window around on the desktop (up/down as well as right/left) and refresh your desktop after each move. a) Is the offset from the upper-left corner of the Fxtv video area to the video "data block" the same in each case? b) Is the size of the video block the same in each case? b) Now resize the video window and refresh your desktop. Does the offset to the video block change depending on the size of the Fxtv window? c) Is the height of the video block always the height of the video window? d) How does the width of the video block vary with the width of the video window? (3) Try adding these two lines: printf( "%x %d\n", x->base_addr, Bpp ); exit(0); below this line: video.addr = x->base_addr + (g.y * x->pitch + g.x) * Bpp in tvscreen.c, and then run fxtv as described in (1). First, check that the second number is "4". Check that the first number (in hex) is the same as the number that gets printed when you run "startx -- -probeonly" from the console. For example: |XFree86 Version 3.3.1 / X Window System |(protocol Version 11, revision 0, vendor release 6300) ... |Release Date: August 4 1997 |(--) SVGA: PCI: Matrox MGA 2164W rev 0, Memory @ 0xfa000000, 0xf8800000 ... |(--) SVGA: Linear framebuffer at 0xFA000000 ^^^^^^^^^^ This number (4) For kicks, try "fxtv -disableDirectV" and make sure that looks cool. Hope this helps you track the problem down. Randall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980519190806.B4820>