[pvrusb2] No more than 16 standards (xawtv bug.) "secam-L is back" closed

[Mike Isely]

On Mon, 14 Aug 2006, xavier.gnata at free.fr wrote:

> Hi,
>
> 2.6.18 pvrusb2 code finds more than 16 stardards (For instance, SECAM-B is not
> found by pvrusb2-mci-20060726 whereas it is by 2.6.18)

The actual set of standards which the pvrusb2 driver pays attention to are 
interpretted out of tveeprom.ko.  I've been away for a few weeks, but 
before I disappeared there was some discussion about tveeprom reporting an 
incomplete set of supported standards.  It's entirely plausible that newer 
tveeprom modules have recent changes to report more standards available. 
The pvrusb2 driver is merely passing this through to the app.

I'll bet if you try the pvrusb2-mci-20060726 standalone driver snap 
against 2.6.18 (you _can_ do this), then the results will be the same as 
the in-kernel pvrusb2 driver.

>
> It is absolutely great. No problem on pvrusb2 side.

Agree.

>
> The problem was line 77 in in xawtv code:
> #define MAX_NORM    16
>
> Well, engineers are so clever that there are more than 16 TV standards all over
> the world...
>
> The obvious (and tested) solution is to have,
> #define MAX_NORM    32

There are currently less than 32 unique bit definitions in V4L2 for video 
standards.  However there are some valid standard choices which involve 
combinations of those bits, for example PAL-B/G (which is PAL-B for one 
freq band and PAL-G for another).  So 32 might not be a large enough 
number.  But it's probably good enough for now.

>
> Grerd : Is it possbile to include this fix in a new xawtv snapshot?
>
> As a result, "secam-L" is back issue is clossed from my point of view.
>

   -Mike


-- 
                         |         Mike Isely          |     PGP fingerprint
      Spammers Die!!     |                             | 03 54 43 4D 75 E5 CC 92
                         |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 C1 E8
                         |                             |