Date: Thu, 13 Mar 1997 22:44:56 -0700 From: Steve Passe <smp@csn.net> To: Randall Hopper <rhh@ct.picker.com> Cc: multimedia@FreeBSD.ORG Subject: Re: Mixed results w/ WinCast/TV Message-ID: <199703140544.WAA22139@Ilsa.StevesCafe.com> In-Reply-To: Your message of "Thu, 13 Mar 1997 20:14:22 EST." <19970313201422.30802@ct.picker.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703140544.WAA22139>