Date: Sat, 15 Mar 1997 23:00:19 -0700 From: Steve Passe <smp@csn.net> To: Amancio Hasty <hasty@rah.star-gate.com> Cc: "Louis A. Mamakos" <louie@TransSys.COM>, multimedia@freebsd.org Subject: Re: latest bt848 code Message-ID: <199703160600.XAA23772@Ilsa.StevesCafe.com> In-Reply-To: Your message of "Sat, 15 Mar 1997 21:28:49 PST." <199703160528.VAA03601@rah.star-gate.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, > Hi Louis, > > Just get the bt848 distribution from Steve's web page: > http://freebsd.org/~fsmp/HomeAuto/Bt848.html > > Then apply the posted patch. > > If you have any problems with that please let us know. > ... > >From The Desk Of "Louis A. Mamakos" : > > I had to add back in some of the meteor ioctl's so that the fxtv program > > would continue to work OK. I didn't realize that I had removed any ioctl's, thought I only added new ones. I grabbed the tarball from the web page and indeed I did remove the METEOR versions, pass the pointy hat this way! When I get that machine up again I will restore them. I haven't rebuilt fxtv in awhile so I didn't notice my fubar (how embarassing). Unfortunately grabbing the latest web page driver and adding Amancio's patch file will make xtvremote happy and eliminate the freeze problem in the driver, but will not help fxtv compile till fxtv is updated to use the new BT848 specific ioctl()s. This is the correct solution as the bt848 specific ioctls do things "the right way" for the hardware, while the METEOR versions compromise by loosing some precision (and the chroma call is fairly hosed as the bt848 sets U and V independantly with different ranges while the METEOR version puts the "one" value into both regs). Long term we need to develop an API for this stuff so an app doesn't need to know about the hardware specifics, -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703160600.XAA23772>