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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704250115.SAA05395>