From owner-freebsd-multimedia Thu Mar 13 21:45:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA24475 for multimedia-outgoing; Thu, 13 Mar 1997 21:45:08 -0800 (PST) Received: from Ilsa.StevesCafe.com (sc-gw.StevesCafe.com [205.168.119.191]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA24469 for ; Thu, 13 Mar 1997 21:45:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.7.5/8.6.12) with SMTP id WAA22139; Thu, 13 Mar 1997 22:44:56 -0700 (MST) Message-Id: <199703140544.WAA22139@Ilsa.StevesCafe.com> X-Authentication-Warning: Ilsa.StevesCafe.com: Host localhost [127.0.0.1] didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Randall Hopper cc: multimedia@FreeBSD.ORG Subject: Re: Mixed results w/ WinCast/TV In-reply-to: Your message of "Thu, 13 Mar 1997 20:14:22 EST." <19970313201422.30802@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Mar 1997 22:44:56 -0700 Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > Steve Passe: > |I also need to deal with the fact that U and V have different ranges. Ie > ... > I'd vote for allowing U & V to be set separately, and in general for I've done this, but will also leave the old version in. --- > all parameters, remapping the values though the driver interface so 0% is > always 0 and the value isn't hardware-specific, if possible. For example, > in general: > > 0 = 0% > 1 = 0.1% > ... > 1000 = 100.0% > > Having (e.g.) 200% be the same value regardless of card would be nice, and > out of range values would just be clipped by the driver to the max > supported by the hardware. > > The app writer's probably going to need some card-specific info any > way we go though. That is, with the generalized values described above, > they need to know what the absolute percentage range limits are valid for > that value on that card to be smart about user input. With the other > scheme where we scale the full hardware range up to some predetermined > numbers (0..SHRT_MAX or whatever), the app writer needs to know what > SHRT_MAX equates to percentage-wise for that card, again to be provide > a useful UI. I'm going to toss this idea around for awhile, it sounds like a good approach. For now I've added a set of defines to ioctl_bt848.h that state the min, max, center, etc. for each of the controls. --- > A third option that comes to mind is just limiting the driver > interface to the lowest range of any card supported by that interface. > While this'd initially remove the need to communicate hardware limits in > some form, I don't think it's practical as these limits might need moved > down in the future, and its a shame not to be able to fully-utilize the > hardware. I agree, not the way to go. --- > Getting these hardware limits (in some remapped form) without being > card-specific in the app is why I was suggesting possibly an ioctl to fetch > a "parameter domain" structure for the driver parameters. That way, the > app doesn't have to be cognizant of what hardware its dealing with and have > a big hackin' switch statement to select the appropriate min/max #define > for each driver param based on what type of card it knew it was dealing > with (which'd need to be updated as hardware was added). I previously called this aproach "kernel bloat" but stated this way I think you've convinced me it would be "the good thing". -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD