From owner-freebsd-multimedia Thu Apr 17 15:27:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA10528 for multimedia-outgoing; Thu, 17 Apr 1997 15:27:00 -0700 (PDT) Received: from gdi.uoregon.edu (gdi.uoregon.edu [128.223.170.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA10520 for ; Thu, 17 Apr 1997 15:26:57 -0700 (PDT) Received: from localhost (dwhite@localhost) by gdi.uoregon.edu (8.8.5/8.6.12) with SMTP id PAA12657; Thu, 17 Apr 1997 15:26:53 -0700 (PDT) Date: Thu, 17 Apr 1997 15:26:52 -0700 (PDT) From: Doug White X-Sender: dwhite@localhost Reply-To: Doug White To: Amancio Hasty cc: Randall Hopper , multimedia@freebsd.org Subject: Re: Fxtv 0.4 In-Reply-To: <199704170725.AAA00325@rah.star-gate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 17 Apr 1997, Amancio Hasty wrote: > >From The Desk Of Doug White : > > The newest version of the driver breaks my system worse than it already > > was. :( You can look at what I get out from a screenshot at > If I am not mistaken you need to modify the driver to work in your case. > remember the mods that you did to the driver?? > > > > http://gdi.uoregon.edu/redscreen.gif. It looks like the gamma correction > > is off in the RGB_24 case. It says it's falling back to Ximage, btw. > > > > Why are the color_ctl flags _forced_ to the settings with = and not |= in > > rgb_prog? I'm probably asking the wrong person, so this is to the list... > > It doesn't matter for now because we are not doing byte or word swapping. Erm, okay. As I mentioned my video is messed up anyway; I'm not getting smurfs, I'm getting black shapes (ie white<->black inversion) in direct video mode. > In the same routine there is this comment: > > /* FIXME: why set colorbars for 1 instant ??? */ > bt848->color_ctl = BT848_COLOR_CTL_COLOR_BARS; > /* FIXME: undone 4 lines later, why bother ??? */ > bt848->color_ctl = BT848_COLOR_CTL_GAMMA; > > Careful here because some of this stuff was written after I read > Brooktree's DOS demo. Some of these chipsets are cranky and yes > we can experiment by taking the lines out. This sort of assignment is what confused me (and John-Mark Gurney, who does some documentation work and is a committer). We were going to put the changes into the start_(whatever) function, but after further research we found this stuff that basically spammed our changes. So we went into rgb_prog and put the change in after it got done doing assignments. I didn't feel like playing around and seeing what's important and what's not -- I assumed since it was there it was doing some sort of initialization with the card, perhaps playing with it a bit to make sure the card is in a known state. > I am going to go thru the driver and examine each FIXME comment. Cool, thanks. Doug White | University of Oregon Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant http://gladstone.uoregon.edu/~dwhite | Computer Science Major