From owner-freebsd-multimedia  Thu Apr 24 17:56:40 1997
Return-Path: <owner-multimedia>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id RAA14015
          for multimedia-outgoing; Thu, 24 Apr 1997 17:56:40 -0700 (PDT)
Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA14010
          for <multimedia@freebsd.org>; Thu, 24 Apr 1997 17:56:38 -0700 (PDT)
Received: from ct.picker.com by whqvax.picker.com with SMTP;
          Thu, 24 Apr 1997 20:56:07 -0400 (EDT)
Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1)
	id AA12386; Thu, 24 Apr 97 20:56:06 EDT
Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4)
	id UAA06124; Thu, 24 Apr 1997 20:55:46 -0400
Message-Id: <19970424205546.59756@ct.picker.com>
Date: Thu, 24 Apr 1997 20:55:46 -0400
From: Randall Hopper <rhh@ct.picker.com>
To: multimedia@freebsd.org
Cc: John-Mark Gurney <gurney_j@resnet.uoregon.edu>,
        Amancio Hasty <hasty@rah.star-gate.com>,
        Doug White <dwhite@resnet.uoregon.edu>
Subject: Fxtv 0.41
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
Sender: owner-multimedia@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

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