Re: Problem with cx25840 and Terratec Grabster AV400

[Sven Barth <pascaldragon@googlemail.com>]

Hi!

On 24.04.2010 22:24, Mike Isely wrote:
> On Sat, 24 Apr 2010, Sven Barth wrote:
>>
>> Hi!
>>
>> Although you never really completed that support for the AV400 it runs pretty
>> well once you've touched the cx25840 source. I'm using it for months now and
>> it runs better than it did with Windows (I sometimes had troubles with audio
>> there which led to an "out of sync" audio track).
>
> Unfortunately I can't really "say" it is supported in the pvrusb2 driver
> until it actually works well enough that a user doesn't have to hack
> driver source (pvrusb2 or otherwise).  Otherwise I'm just going to get
> inundated with help requests for this.  Not having a sample of the
> device here I'm handicapped from debugging such issues.
>

I don't want to have this hacking as much as you do. But currently it's 
the only way that works for me (I'm really glad that it has come that 
far ^^)...
I'll try to help here as good as I can (and time permits) to solve this 
issue.

> I've just made a change to the pvrusb2 driver to allow for the ability
> to mark a piece of hardware (such as this device) as "experimental".
> Such devices will generate a warning in the kernel log upon
> initialization.  The experimental marker doesn't impact the ability to
> use the device; it just triggers the warning message.  Once we know the
> device is working acceptably well enough, the marker can be turned off.
> This should help avoid misleading others about whether or not the
> pvrusb2 driver fully supports a particular piece of hardware.
>

No offense intended, but do you really think that people will read that? 
Normal users (using Ubuntu, etc) don't really care whether their device 
is marked as experimental or not... they just want it to work and thus 
can go to great lengths to "disturb" the developers working on their 
driver...

>> PS: Did you read my mail from last December?
>> http://www.isely.net/pipermail/pvrusb2/2009-December/002716.html
>
> Yeah, I saw it back then, and then I probably got distracted away :-(

I know that problem pretty well. ^^ I was only curious.

>
> The key issue is that your hardware doesn't seem to work until you make
> those two changes to the v4l-dvb cx25840 driver.  Obviously one can't
> just make those changes without understanding the implications for other
> users of the driver.  I (or someone expert at the cx25840 module) needs
> to study that patch and understand what is best to do for the driver.
>
>    -Mike
>
>

It would be interesting to know why the v4l devs disabled the audio 
routing for cx2583x chips and whether it was intended that a cx25837 
chip gets the same treatment as a e.g. cx25836.
And those "implications" you're talking about is the reason why I wrote 
here: I want to check whether there is a better or more correct way than 
to disable those checks (it works here, because I have only that one 
device that contains a cx2583x chip...).

Just a thought: can it be that my chip's audio routing isn't set to the 
correct value after initialization and thus it needs to be set at least 
once, while all other chips default to a working routing after 
initialization? Could be a design mistake done by Terratec...

Regards,
Sven