From owner-freebsd-multimedia Sun Jul 12 06:15:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA24249 for freebsd-multimedia-outgoing; Sun, 12 Jul 1998 06:15:13 -0700 (PDT) (envelope-from owner-freebsd-multimedia@FreeBSD.ORG) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA24244 for ; Sun, 12 Jul 1998 06:15:11 -0700 (PDT) (envelope-from rhh@ct.picker.com) Received: from ct.picker.com by whqvax.picker.com with SMTP; Sun, 12 Jul 1998 9:13:36 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA03823; Sun, 12 Jul 98 09:13:36 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id JAA17128; Sun, 12 Jul 1998 09:13:09 -0400 Message-Id: <19980712091308.A17097@ct.picker.com> Date: Sun, 12 Jul 1998 09:13:08 -0400 From: Randall Hopper To: Kevin Day , Amancio Hasty Cc: multimedia@FreeBSD.ORG Subject: Re: bt878 support Mail-Followup-To: Kevin Day , Amancio Hasty , multimedia@freebsd.org References: <19980711193123.A15158@ct.picker.com> <199807120056.TAA09961@home.dragondata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199807120056.TAA09961@home.dragondata.com>; from Kevin Day on Sat, Jul 11, 1998 at 07:56:14PM -0500 Sender: owner-freebsd-multimedia@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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