[pvrusb2] pvrusb2 driver status...

[Mike Isely]

Just thought I'd drop a note as to what is going on with the pvrusb2 
driver.

First, there are a number of fixes that need to go into the driver.  These 
include:

  - Tweak to allow xawtv to function again

  - Solution for wm8775 autodetection problem (for new hardware)

  - Solution to keep msp3400 from messing with the driver (for new hardware)

  - AMD64 compilation fix

  - Possible compilation tweak to help with some kernels

There's probably more that I'm forgetting, but I've got a list written 
down.

Oh, and I'm working on rewritten documentation, which hopefully will be 
better organized, easier to follow, and will include full information on 
how to use this driver with the model 24xxx series (new hardware).  I did 
a chunk of work on that last weekend, until the xawtv issue took my 
attention.

In addition to that, I have a big rework coming up for the handling of 
internal controls within the driver.  This was triggered by the effort to 
get the driver into the 2.6.17 kernel, and while that didn't make it, I 
had already started tearing into the code for this and I prefer to finish 
what I started.  At the moment, there are 3 forks of the driver source and 
I need to pull that back together - so first on the plate is to finish 
this controls rework.  Most of that work is done as of tonight.  Once I 
convince myself that it doesn't horribly break things, then I'll turn my 
attention to the above listed fixes and release a new snapshot.

The outward behavior with this controls rework won't be that much 
different.  However with it will come new code for handling video 
standards properly.  What's been there to-date has been a hack, due partly 
to what the driver was doing before I started working on it and also due 
to my lack of understanding for how V4L does video standards.  That's all 
changed now.  What's coming should allow the driver to work correctly with 
_every_ video standard currently defined and supported in V4L2.  The new 
code does this algorithmically generating an enumerated list of standards 
corresponding to exactly what the hardware reports - and there will also 
be a module option to override what the hardware reports.  This should in 
theory allow you to specify any video standard, and if it is within the 
scope of what the hardware can do, then it should work.  In theory...

The controls rework also introduces a few minor changes in the sysfs 
interface that should make it easier to handle things which involve bit 
masks.

Hopefully it won't be too much longer before I get another snapshot 
available.

   -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
                         |                             |