pvrxxx, linux code and modules

[Greg 'groggy' Lehey]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-multimedia/attachments/20070427/d40431f1/attachment.pgp