From owner-freebsd-multimedia@FreeBSD.ORG Fri Apr 27 05:47:35 2007 Return-Path: X-Original-To: freebsd-multimedia@freebsd.org Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E183316A400 for ; Fri, 27 Apr 2007 05:47:35 +0000 (UTC) (envelope-from grog@lemis.com) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.freebsd.org (Postfix) with ESMTP id 7241413C44B for ; Fri, 27 Apr 2007 05:47:35 +0000 (UTC) (envelope-from grog@lemis.com) Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.135]) by ozlabs.org (Postfix) with ESMTP id 9CED6DDF85; Fri, 27 Apr 2007 15:47:33 +1000 (EST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 5F4291A986F; Fri, 27 Apr 2007 15:17:33 +0930 (CST) Date: Fri, 27 Apr 2007 15:17:33 +0930 From: Greg 'groggy' Lehey To: Jim Stapleton Message-ID: <20070427054733.GF15734@wantadilla.lemis.com> References: <80f4f2b20704230529s706c50a9pa4716e74c2b04182@mail.gmail.com> <20070424001346.GF45246@wantadilla.lemis.com> <80f4f2b20704241029x68e18eddgad417a71195d2666@mail.gmail.com> <80f4f2b20704230529s706c50a9pa4716e74c2b04182@mail.gmail.com> <20070424001346.GF45246@wantadilla.lemis.com> <80f4f2b20704240519u1cedb1ady1738268947a15a3d@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6v9BRtpmy+umdQlo" Content-Disposition: inline In-Reply-To: <80f4f2b20704241029x68e18eddgad417a71195d2666@mail.gmail.com> <80f4f2b20704240519u1cedb1ady1738268947a15a3d@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 VoIP: sip:0871270137@sip.internode.on.net WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: freebsd-multimedia@freebsd.org Subject: Re: pvrxxx, linux code and modules X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2007 05:47:36 -0000 --6v9BRtpmy+umdQlo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tuesday, 24 April 2007 at 8:19:39 -0400, Jim Stapleton wrote: >> I think that the Linux drivers do something similar to this, modulo >> kernel constraints. If it's really practical to have this in >> userland, having a proper configuration file makes a lot of sense. > > Should I write some code for it then? Are you in a position to do that? On Tuesday, 24 April 2007 at 13:29:04 -0400, Jim Stapleton wrote: > I have a question regarding the tuner identification process... > > Namely, what are the pieces pieces of identification are needed to > identify the tuner, and how uniform are they between card make/models? Good question. > ex: > In the driver I see a 1 byte eeprom code (Eh), and a 1 byte tuner code (Th). > > Is it safe to assume that with these two codes, the tuner will always > be identifiable? (i.e. lets say a Leadtek card uses the same tuner, > will I be able to take one byte from the Leadtek eeprom for it's > eeprom code (El), and one byte for it's tuner code (Tl), and be able > to determine the tuner, or might I need multiple bytes for El and/or > Tl? Will they always be integers? Could strings be expected? My problem is that I don't know much about the tuners myself. That's a thing I'm planning to do when I have time. Judging by the lack of response from others, I'd guess that they don't have a definitive answer either. But from what I've heard, I suspect it's a good idea not to rely on anything. > I'm just curious how much more data will need to be packed into the > text entries on the files... And how much can be put there to make > the tuner drivers as generic as possible (theoritically, it'd be > nice to have one tuner driver that would work with any > television/radio card, which would be able to determine the tuner, > without the other drivers having to do calculations on the > eeprop/card data). Right. But of course, once you've written your whiz-bang, supports everything software, some manufacturer will come along and introduce a card that breaks your software. The best I can recommend here would be to grab a few cards that you know about and write an expandable syntax that is enough to handle them. Then when others come along, you can modify things. I'm not sure how that would look in practice. Greg -- See complete headers for address and phone numbers. --6v9BRtpmy+umdQlo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFGMY51IubykFB6QiMRAvboAJwPsViw2+w5BAQZd4NIy8+vBWIYdgCghZkI bUWVskM54Ijyn7iZjSTkvRg= =RQfA -----END PGP SIGNATURE----- --6v9BRtpmy+umdQlo--