Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 13 Mar 1997 20:14:22 -0500
From:      Randall Hopper <rhh@ct.picker.com>
To:        Steve Passe <smp@csn.net>
Cc:        multimedia@FreeBSD.ORG
Subject:   Re: Mixed results w/ WinCast/TV
Message-ID:  <19970313201422.30802@ct.picker.com>
In-Reply-To: <199703121907.MAA00286@Ilsa.StevesCafe.com>; from Steve Passe on Wed, Mar 12, 1997 at 12:07:35PM -0700
References:  <Pine.BSI.3.94.970311223050.1189B-100000@localhost> <199703121907.MAA00286@Ilsa.StevesCafe.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Steve Passe:
 |I also need to deal with the fact that U and V have different ranges.  Ie
 |you can't stuff the same value into both registers and get the "correct"
 |result: 100% is 0xfe in the U reg, but 0xb4 in the V reg.  not sure
 |whether to change the ioctls to have seperate entries for U and V,
 |letting the app writer do the correction math, or to have 1 ioctl that
 |does the relative adjustment based on a passed in value in the range of
 |??? thru ???.  guess the range would have to be 0% thru 201%, ie the
 |lesser of U and V.

     I'd vote for allowing U & V to be set separately, and in general for
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.

     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.

     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).

     Wow.  That turned out to be longer than I thought.  I guess that's
called talkin' yours eyes off.  :-)

Randall



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970313201422.30802>