Skip site navigation (1)Skip section navigation (2) 
Date:      Sat, 8 Nov 1997 16:07:37 -0500
From:      Randall Hopper <rhh@ct.picker.com>
To:        Eivind Eklund <perhaps@yes.no>, Tomi Vainio <tomppa@fidata.fi>, Joao Carlos Mendes Luis <jonny@coppe.ufrj.br>
Cc:        Amancio Hasty <hasty@rah.star-gate.com>, freebsd-multimedia@FreeBSD.ORG
Subject:   bt/fxtv 24bpp & img cnvt patches (was Re: Bt848 driver patches)
Message-ID:  <19971108160737.19314@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 

[-- Attachment #1 --]
Eivind Eklund:
 |(1) A single steady vertical line when the fxtv window is in some
 |position in the upper and lower right corner of my screen
 |(1600x1200x16 bit) - the rest of the window work normally.  This one
 |seems likely to be a splitting problem, IFF the split is done as to
 |rectangles vertically.  It seems to be related to the size of the
 |window; I've had some problems repeating it at will, but get it
 |from time to time.

Two patches attached.  Both will apply cleanly to the 971105 driver and
Fxtv 0.46 (both on the Fxtv page).

"bt848-24bpp-971108.patch" fixes:

   - The occasional vertical black line divider line in the video window 
       (packed 24bpp direct video)
   - The occasional screwed up colors (packed 24bpp direct video)

"fxtv-0.46-1-ximage.patch" fixes:

   - Bunch o' byte swapping and ximage pitch handling fixes
     (ALL bpp ximage modes).  These should fix stairstep video, surreal
     color problems, as well as a few "unsupported color conversion"
     bail-outs people have seen.
   - Added 3Bpp->3/4Bpp conversion support, also fixes "unsup col conv" probs

Please try em out and make sure they work as advertised on your box.  Try
all your server's color depths, and be sure to to do at least one freeze
frame to verify that, not just direct video, but ximage transfer is working
too.

Let me know about any configurations that don't work for you.  I'd like to
wrap these up and get everybody supported without any patching needed.

If you see a problem, the following info would be helpful:

     - Graphics card
     - X Server vendor   (XFree,Xaccel)
     - X Server version  (3.3.1)
     - X Server          (SVGA,S3V,etc.)
     - Color depth       (8,15,16,32)
     - "appres Fxtv" output
     - "fxtv -debug startup" output

                                -----------     

Driver Patch

In case anybody's interested (or collecting tidbits for a Bt848 hackers
guide), the "vertical black divider line" problem is due to the way the
Bt848 processes a WRITE instruction.  When it hits one of these, it
resynchronizes Byte Lane 0 of the current FIFO dword to Byte 0 of the
memory dword containing the starting transfer address ("not" the transfer
address itself).  So when a the driver's RISC program splits a scan line
into 2 halves (two WRITEs), the second WRITE's resync causes a pixel to be
dropped if it didn't occur in a "lucky" spot (see below).

A WRITEC doesn't perform this alignment resync (the main reason for even
having this instruction), so a WRITEC is now used for the last half of the
scanline.  And no more black line.

Once I found this out, it was appearent why the colors in a packed 24bpp
direct video window are whacked depending on where you put the window.  In
RGB24 mode, the pixels in each scan line roll off the Bt FIFO like this:
BGRBGR...  And in a packed-24bpp frame buffer that's Bt848
direct-video-compatible, the scan lines look like this:

                0  1   2   3   4  5   6   7 
                BGRB GRBG RBGR BGRB GRBG RBGR ...

Given the WRITE resync behavior described above, the FIFO components will
align with the frame buffer if the starting transfer address is at pixel
offsets 0,1,4,5,... (in general X % 4 == [0 or 1]), but they'll be out of
sync for 2,3,6,7 (X % 4 == [2 or 3]).

The solution here is to toss 1 or 2 DWORDs at the beginning of a scan line
(SKIP) for the X%4=[2,3] cases to align the FIFO with the dword at the
target memory address in the frame buffer.

                                -----------     

Fxtv Patch

All these fixes relate to XImages transfer mode (which is used for freeze
frame, when the window is partially occluded by other window(s), and when
fxtv doesn't think the video card is compatible with direct video in a
particular color depth).

Byte order problems fixed.  Use the byte order the server specifies for
XImages, rather than erroneously using the frame buffer byte order (which
must be specified by the user).  Also do more intelligent swapping when
converting between pixel geometries.  Both these problems would have
appeared before as surreal or reversed colors on the video frame.

XImage pitch problem fixed.  Sometimes (e.g. in 8bpp) there will need to be
pad bytes allotted at the end of scan lines -- these weren't being put in
before, potentially causing diagonal video frames for some video widths.

Finally, added support for 3Bpp->3/4Bpp conversion.

With these changes, colors look correct for me on my STB Velocity 3D in all
color depths for both direct video and ximages transfer for both the SVGA
and S3V servers on XFree 3.3.1.  

Please test all permutations on your card and let me know!

Randall

[-- Attachment #2 --]
d4bt848-24bpp-971108.patchVaOHw:8N	 HK{hA4Rt:Y{C,leеov!	~μy;,Vzgx躝~;>gupZr!ۏL:Ce	wo89'YQd$¨`#X.xlPD
^^?8+Z`i(EXؙG<L9"}%WB;ҙySy^Ԛn6\w35,9~@(y;q<&1fYo^MP&54kϣ͛IƝtU:
1ALȖ~`9
HpJUcpD\?j<MKFT@!2H"nH493R/̈9qew;+gqBqe-rgZR7B뵰H9!r)ONBL%#@:PU<(w3e@	O.ENDdQ(%ܤy{g6K0*6(0K>ۭ>Tn\{ZQx#^G6w}1ڿ:cՙOXS`&;2¶kMOdzݐFc=6~AOGpJ#'ݎFcWD2

3}_?x?^]O
yGyƍQ֋2uI_Ũ:Ar-5GH[{i_cZ,:;iG&rqc,CXsQ5&ZU*iWؕm:l3ƿ}Ԗ{W?i֩hkߟ֩P=y9sǙNm=c32WOyWA|S?
AL쨞TgVTJ*_x3^j;[փڠT|ȋ4vPE?KSJ]nPz~^q'$Tħ6ʡBzj6[K+^/BKwE_P^:tP);g*]rAn(醕t,{O]tJ3vC"B`2)t^<4mo{^+sL=XRFtv/lijTi&WUFZ`$^	HOA
HHQ<}&T̖`If,4iV茋,dݶ:婒6f$X i)#Mr#
дr:yw*6$i2Nӡ
[-- Attachment #3 --]
%d4fxtv-0.46-1-ximage.patchksHs+z}2`؉YeH6w%V+	Ǿ~3zx8Wٻb*eL2xwnal\l')szeR݃{b1F	&Tu}_^^Ԁ"+lL6N_u.zN
Hc`OC&Nka
-sc[;ŀv緣KpA~"w<}@FRCx*M(''6I`,0T9c0׵$I[g,4l`pϲnH,ʐOұX2g
b\ziͽfZu߻a|82?>U?ܕoDz	)@77`ScjLt?nw.w%xu^2IJK
i
x\T#?x1#Q
mr\/F2$.G=E2?L}<猔ɓJgE8WRr<7q]qmk.Zs<.-PZ_fG$P>\mSu)k@;[}q!Sf)C8>{kt:X=[I}	}a}j-2	\9m2^wNw_ޜ}l>2юkK% R'y>tz=
i}}n)Hsiw[JoZ8Rd1z.y</u?r~bM%/:}M-z:hńZm$ċUx1xsm|EߨWO;u%lǁctwFs\_:l"(-
zCrs~$NOa7ƴg"weuR7AHe(˯E
&9BAGAk
CdC 7<灋Ea|ɧE\Mr݋b.@1K.\‰2<"߇5D7MW<Ą=F	T!V&@F{Y!#1d'I ,qIz+KgcV6bkQe}nCayɟSL"JhOV>Ҍ`FѤHJ1]$qTEYp%1B498cx24{$́uCkb&0-$+l-WL`
	I`0nDOSSˢAoOBB.j|Ws@|stx1v3D@C@󥄟3
@+|~
r4R^^HݸBu1gzJ8I8pd~"!{i'MFvvs4t
ӳOʣ|Mi]}(B?gBmO-ie&!YSrAԥ\Mo\yR2Xd-x,EHLYXh|
nX7k%:(9e_|f#73Z(m/\&J3IdlQB,q!J4d_Sg#0b~JYz`afP"Q,3AWOӅk J){_4PmFeHd҃uF	K")֊st]A?HvbN!	bTުgg? TaT UU?fi\y]ea\RO)-ԒکMUjL+jKeOiyT6wX}hiMKJs :~F^-6BZIE_-ϩa4Z]1[pܦ4e>W:`_ygAwgWqtcg1rH}:`zgLtN}bYe_iit(usH@jQR-̌b@I&"n,c}b=NӤ}Pᑅ]R(us"w KJUsZZJ4Hg{cz@d$& rخhri^:?D\tYd袆pYGhO1ĦJcjˢ,,?X3qB4Ϳ (j㿬L|b/R};;r?U>s܊G&OXBOH@aa}a5?&HB2$1H0ܗFĵe[B*.(I!īģ;[a6''	RT\&$&E7-K1yƵɾZ'E=MA}5G/8!((or/H
z=k3.h!*i?*	!gJ(.Ty5Կ9&ЧX<Ǯ0u*&X$j}XٵWVW_^IoBQoVj.G+__P\.˵dSqNJ^^Kbv-T
qWI'czvMnN[=f";Wp q"kv/5#4eIUOjٻ˱ZcŚt^4'jskY!eso?z
=

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