From owner-freebsd-multimedia Thu Mar 13 17:24:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA03159 for multimedia-outgoing; Thu, 13 Mar 1997 17:24:37 -0800 (PST) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id RAA02915 for ; Thu, 13 Mar 1997 17:17:38 -0800 (PST) Received: from ct.picker.com by whqvax.picker.com with SMTP; Thu, 13 Mar 1997 20:17:00 -0500 (EST) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA04667; Thu, 13 Mar 97 20:16:58 EST Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id UAA17298; Thu, 13 Mar 1997 20:14:22 -0500 Message-Id: <19970313201422.30802@ct.picker.com> Date: Thu, 13 Mar 1997 20:14:22 -0500 From: Randall Hopper To: Steve Passe Cc: multimedia@FreeBSD.ORG Subject: Re: Mixed results w/ WinCast/TV References: <199703121907.MAA00286@Ilsa.StevesCafe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.65 In-Reply-To: <199703121907.MAA00286@Ilsa.StevesCafe.com>; from Steve Passe on Wed, Mar 12, 1997 at 12:07:35PM -0700 Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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