From owner-freebsd-multimedia Sat Nov 8 13:33:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA24764 for multimedia-outgoing; Sat, 8 Nov 1997 13:33:54 -0800 (PST) (envelope-from owner-freebsd-multimedia) 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 NAA24750 for ; Sat, 8 Nov 1997 13:33:50 -0800 (PST) (envelope-from rhh@ct.picker.com) Received: from ct.picker.com by whqvax.picker.com with SMTP; Sat, 8 Nov 1997 16:32:47 -0500 (EST) Received: from elmer.ct.picker.com by ct.picker.com (4.1/SMI-4.1) id AA08663; Sat, 8 Nov 97 16:32:46 EST Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id QAA15438; Sat, 8 Nov 1997 16:32:21 -0500 Message-Id: <19971108163221.24955@ct.picker.com> Date: Sat, 8 Nov 1997 16:32:21 -0500 From: Randall Hopper To: Eivind Eklund Cc: Amancio Hasty , tomppa@fidata.fi, freebsd-multimedia@FreeBSD.ORG Subject: Re: Bt848 driver patches References: <199710291417.PAA01941@bitbox.follo.net> <199710301744.JAA09896@rah.star-gate.com> <19971030194225.11523@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <19971030194225.11523@bitbox.follo.net>; from Eivind Eklund on Thu, Oct 30, 1997 at 07:42:25PM +0100 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Eivind Eklund: |(2) DMA to the wrong position (horizontal offset) when the screen is |32 bits deep. I don't have any clue as to whether this would be an |XFree86, brkt (kernel driver) or fxtv problem. I'm guessing this might be because you haven't got the Fxtv "Bpp" resources configured correctly to match your frame buffer's pixel geometry. Do an: appres Fxtv | egrep 'swap|Bpp' and look at the Bpp settings. For example: Fxtv.Bpp24bit: 3 Fxtv.Bpp32bit: 3 This says that in modes with visuals that "claim" to be 24bpp, the frame buffer is really in a 3 Bpp (byte per pixel) mode. If you're video is shifted to the right of the video window, tweak the number for the corresponding BppXbit setting down (likely from 4 to 3). If its shifted to the left, bump the BppXbit setting up. I know this "divining" of the true frame buffer pixel geometry is a bit of a pain. However, the need to do this might go away sometime. One of the XFree developers has mentioned to me though that next version of XFree will likely provide an API that DGA programs can use to get this information (along with other frame buffer pixel geometry info including true masks and byte swaps) from the X server. Then Fxtv won't have require the user to figure out and specify this info. |(3) Swapped lines (?) I had something that looked like line |interchange once, but it went away when I increased the size of the |window. Probably out of sync interlacing hardware. Not reproduced, |and might be just 'sleight of the eye' - I have an extreme resolution, |so it is hard to see. Was this in ximages mode? If so, when you're running in larger 3 and 4 Bpp true-color, the latency of converting frames gets to be quite high even for 322x242 windows. On my 233MMX I've noticed that in 3Bpp true-color if I disable the bcopy() ximage transfer and force it to do per-pixel conversion (which'll happen all the time if the frame buffer is RGBRGB...), the speed almost resonates sometimes at a multiple of the frame rate so the even and odd frames aren't typically from the same frame. This produces a fields-out-of-sync looking effect that sounds like what you're talking about. Try tweaking your Fxtv "Bpp..." and "swap..." resources to see if you can't get working in direct video. In 3- and 4Bpp, that'll make a world of difference. Randall