Date: Sat, 8 Nov 1997 16:32:21 -0500 From: Randall Hopper <rhh@ct.picker.com> To: Eivind Eklund <perhaps@yes.no> Cc: Amancio Hasty <hasty@rah.star-gate.com>, tomppa@fidata.fi, freebsd-multimedia@FreeBSD.ORG Subject: Re: Bt848 driver patches Message-ID: <19971108163221.24955@ct.picker.com> In-Reply-To: <19971030194225.11523@bitbox.follo.net>; from Eivind Eklund on Thu, Oct 30, 1997 at 07:42:25PM %2B0100 References: <199710291417.PAA01941@bitbox.follo.net> <199710301744.JAA09896@rah.star-gate.com> <19971030194225.11523@bitbox.follo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971108163221.24955>