Date: Sun, 12 Jul 1998 09:13:08 -0400 From: Randall Hopper <rhh@ct.picker.com> To: Kevin Day <toasty@home.dragondata.com>, Amancio Hasty <hasty@rah.star-gate.com> Cc: multimedia@FreeBSD.ORG Subject: Re: bt878 support Message-ID: <19980712091308.A17097@ct.picker.com> In-Reply-To: <199807120056.TAA09961@home.dragondata.com>; from Kevin Day on Sat, Jul 11, 1998 at 07:56:14PM -0500 References: <19980711193123.A15158@ct.picker.com> <199807120056.TAA09961@home.dragondata.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Kevin Day:
|> 1. Does your TV card feed all 4 Bt878 inputs?
|No. :)
|
|> 2. What are the Bt878 inputs on your card connected to?
|> (tuner, video jacks, svideo jacks, etc.)
|
|I have a tuner in, and a video in. That's it.
|
|> The reason I ask is this: By convention, the mappings for Bt848 input
|> device types -to- bktr input device ioctl #defines are as follows:
|>
|> #define DEVICE TYPE
|> ------- ---------------
|> DEV0 = STD VIDEO INPUT
|> DEV1 = TUNER INPUT
|> DEV2 = SVIDEO INPUT
Amancio Hasty:
|The Bt878 has for input muxes vs 3 Input Muxes for the bt848.
|
|It is up to the application to provide access to the muxes nor do
|I expect Bt878 board manufacturers to standardize on the use of the
|Input Muxes.
|
|vic handles this problem by providing select options for PORT-1, PORT-2,
|PORT-3,
|etc..
>From past mail, I understand that the Bt848 has 4 muxes instead of 3.
But here's the issue:
1. A TV app should present selections to the user in terms of "video",
"tuner", etc. Not "mux 0", "mux 1", "mux 2", "mux 3".
2. The user shouldn't have to know how the HW engineer wired up the
Bt chip to configure or use the TV app.
3. The bktr driver knows what Bt chip, what tuner, what card is installed.
From this it, it can infer which mux input is "video", which is "tuner",
etc.
The app doesn't (and shouldn't) know what Bt chip, what tuner, what
card is installed.
Thus it doesn't know where the tuner, video, etc. is.
Now, the functional API to the driver currently has these semantics:
- "select VIDEO input" (DEV0)
- "select TUNER input" (DEV1)
etc.
This is a "good thing" IMO. Now, they're named with DEV0 and DEV1 due to
legacy reuse of old METEOR symbols, but that's what they are (currently
anyway).
So if we were to follow convention, for these new TV boards, we'd map MUX3
to the video #define (METEOR_INPUT_DEV0). Possibly a little misleading
from the symbol names.
Even better, we can add are more explicit #defines (like the existing
METEOR_INPUT_DEV_SVIDEO) which are, as the name implies, dynamically mapped
to the appropriate input mux based on type. That is, add:
METEOR_INPUT_DEV_VIDEO
METEOR_INPUT_DEV_TUNER
while keeping:
METEOR_INPUT_DEV_SVIDEO
in place.
So basically, we need to keep a method in the driver API to select input
based on input device type: video, tuner, etc. If this is supported, I'll
be happy to put in the follow-through changes to Fxtv.
Randall
brooktree848.c:
case METEORSINPUT: /* set input device */
...
/* this is the RCA video input */
case METEOR_INPUT_DEV0:
...
/* this is the tuner input */
case METEOR_INPUT_DEV1:
...
/* this is the S-VHS input */
case METEOR_INPUT_DEV2:
case METEOR_INPUT_DEV_SVIDEO:
...
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980712091308.A17097>