Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Apr 1997 18:15:07 -0700
From:      Amancio Hasty <hasty@rah.star-gate.com>
To:        Randall Hopper <rhh@ct.picker.com>
Cc:        multimedia@freebsd.org, John-Mark Gurney <gurney_j@resnet.uoregon.edu>, Doug White <dwhite@resnet.uoregon.edu>
Subject:   Re: Fxtv 0.41 
Message-ID:  <199704250115.SAA05395@rah.star-gate.com>
In-Reply-To: Your message of "Thu, 24 Apr 1997 20:55:46 EDT." <19970424205546.59756@ct.picker.com> 

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

Most Cool, 

I am going to give it a try in a few minutes.

Because most of us hold full time positions or get extremely busy with
other projects , I suggest that we pair up on projects .

To all involved in the Bt848 project , you are doing a fine job and 
it shows.

With respect to  bug reports, please keep them coming in don't be shy .
What I really hate to see is after the involved parties move on to 
other projects for the bug reports to start coming in.

	Have Fun Guys,
	Amancio

>From The Desk Of Randall Hopper :
> New rev of fxtv (0.41) and the bt driver (970424) are available at:
> 
>         http://multiverse.com/~rhh/fxtv
> 
>      (Just fxtv-related stuff in this message.  The driver info is in a
> message I just mailed.)
> New rev of fxtv (0.41) and the bt driver (970424) are available at:
> 
>         http://multiverse.com/~rhh/fxtv
> 
>      My goal with this version was to get everyone's TV's working in every
> video mode and pixel weighting their card supports.  I probably didn't get
> all the way, but hopefully this is pretty close.  :-)
> 
>      Support for the added pixel formats in the driver (byte/word swapping
> + 565 16bpp and packed 24bpp [3Bpp]) should enable more folks to run direct
> video in modes they previously, freeing up some major CPU from pixel
> conversion :-)
> 
>      Also, I've beefed up the on-CPU pixel conversion in Fxtv so, in modes
> where direct video isn't an option, you hopefully still stand a good shot of
> being able to watching TV.
> 
>      To aid in identifying and solving byte ordering problems, I've added
> support for Steve's colorbar ioctls, and provided options to specify your
> frame buffer's byte order to fxtv.  Some command line options to try:
> 
>                 ALL MODES:  -colorbars, disableDirectV, -debug startup
>         15bpp/16bpp MODES:  -nobswap2Bpp, -bswap2Bpp
>        24bpp (3Bpp) MODES:  -nobswap3Bpp, -bswap3Bpp
>      24/32bpp(4Bpp) MODES:  -nobswap4Bpp, -bswap4Bpp,
>                             -nowswap4Bpp, -wswap4Bpp,
> 
> ...available as X resources as well, of course, so once you figure out the
> right permutation, put them in your Fxtv class resource file (see the web
> page for examples).
> 
> 
> COLORBARS
> 
>      Note that if everything's in sync, you should see solid (not tiled)
>      colorbars with very pure colors in this order from left-to-right:
> 
>           White  Yellow  Cyan  Green  Magenta  Red  Blue  Black
> 
> 
> TEST PROCEDURE
> 
> In every mode (and pixel weighting), please run:
> 
>      fxtv -colorbars
> 
> and do at least one freeze frame.  Make sure both the continuous video and
> the freeze frame look OK.  If not, play with the swap options for that
> pixel depth (see above).  If there are still problems and its the running
> video that's hosed, try adding -disableDirectV.
> 
> If you don't have any luck, please let me know and attach the output of:
> 
>     fxtv -debug startup
> 
> and any description you can give about what you're seeing (a image grabbed
> from the window would be best).
> 
> 
>      Hope this gets more of you going.  Let me know how it goes.
> 
> Randall
> 
> 





Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?199704250115.SAA05395>