XC5000 improvements: call for testers!

XC5000 improvements: call for testers!

[Devin Heitmueller]

Hello all,

I'm happy to announce that there have been some considerable
improvements to the xc5000 driver, and I am looking for people with
xc5000 based devices to test:

== Noteworthy changes ==

* Power management is now properly supported - no more sucking up your
laptop battery and burning your fingers on the tuner's f-connector
when the device is idle (can be disabled with the "no_poweroff"
modprobe option).

* Faster tuning - average 10x improvement in time to lock.  Average
lock time now around 350ms, down from 3200ms.  No more multi-second
delays when trying to channel surf in tvtime.

* Redistributable firmware - Xceive has graciously allowed us to
redistribute the firmware and bundle it in the distros.  No more need
for users to manually extract the blob from the Hauppauge Windows
driver.

* Various fixes to bridges and dvb core found during power management testing.

* Support for DVB-T tuning, thanks to David T.L. Wong <davidtlwong@gmail.com>

To test the code, clone from the following hg repository:

http://linuxtv.org/hg/~dheitmueller/xc5000-improvements-beta/

Unfortunately, current users are going to have to upgrade to the new
firmware.  However, this is a one time cost and I will work with the
distros to get it bundled so that users won't have to do this in the
future:

http://www.devinheitmueller.com/xc5000/dvb-fe-xc5000-1.6.114.fw
http://www.devinheitmueller.com/xc5000/README.xc5000

Thanks go out to Xceive for providing access to the xc5000
specification, reference driver code, and firmware under the
appropriate license.  Thanks also go out to Michael Krufky for his
considerable effort in helping test/debug different xc5000 hardware.

I look forward to hearing back from testers with any problems they may
encounter.  Now is the time to bring these up before it gets merged
into the mainline.

Thanks,

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: XC5000 improvements: call for testers!

[Devin Heitmueller]

On Wed, May 6, 2009 at 2:47 AM, kenny wang <smartkenny@gmail.com> wrote:
>
> Works perfect on my machines!
>
> Thinkpad T61 + Ubuntu 9.04
> Eeepc 1000HA + Ubuntu 9.04 NBR
>
> When tvtime is launched, it needs the same time to tune as before, but after
> the first channel comes out, switching channels is blazing fast! And the
> temperature is just a little bit higher than my hand. I love this new
> version! Great job, Devin.

Hello Kenny,

That's good news.  Could you please clarify which xc5000 based device
you are testing with?  This information is crucial to my tracking of
which devices have been tested.  If you're seeing slow tvtime startup,
then I am assuming it's an hvr-950q.

Thanks,

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: XC5000 improvements: call for testers!

[Devin Heitmueller]

On Wed, May 6, 2009 at 11:03 AM, kenny wang <smartkenny@gmail.com> wrote:
>
> Yes, Devin, I am using a WinTV-HVR-950Q.

That's what I thought - the delay in loading tvtime is actually
because of some issues with the performance of the au0828's i2c bus.
I've put a few nights of work into debugging it, and I have some ideas
on how to make it perform better, however I wanted to take it out of
the critical path for the xc5000 improvements.

I realize it's annoying for tvtime users and will be working to
improve the situation going forward.

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: XC5000 improvements: call for testers!

[Frank Dischner]

On Wed, May 6, 2009 at 9:16 AM, Devin Heitmueller
<devin.heitmueller@gmail.com> wrote:
> On Wed, May 6, 2009 at 11:03 AM, kenny wang <smartkenny@gmail.com> wrote:
>>
>> Yes, Devin, I am using a WinTV-HVR-950Q.
>
> That's what I thought - the delay in loading tvtime is actually
> because of some issues with the performance of the au0828's i2c bus.
> I've put a few nights of work into debugging it, and I have some ideas
> on how to make it perform better, however I wanted to take it out of
> the critical path for the xc5000 improvements.

I noticed the windows driver actually sends xc5000 commands through
the au8522, and couldn't figure out why. Perhaps this is the reason?

Frank

Re: XC5000 improvements: call for testers!

[Devin Heitmueller]

On Wed, May 6, 2009 at 5:46 PM, Frank Dischner
<phaedrus961@googlemail.com> wrote:
> On Wed, May 6, 2009 at 9:16 AM, Devin Heitmueller
> <devin.heitmueller@gmail.com> wrote:
>> On Wed, May 6, 2009 at 11:03 AM, kenny wang <smartkenny@gmail.com> wrote:
>>>
>>> Yes, Devin, I am using a WinTV-HVR-950Q.
>>
>> That's what I thought - the delay in loading tvtime is actually
>> because of some issues with the performance of the au0828's i2c bus.
>> I've put a few nights of work into debugging it, and I have some ideas
>> on how to make it perform better, however I wanted to take it out of
>> the critical path for the xc5000 improvements.
>
> I noticed the windows driver actually sends xc5000 commands through
> the au8522, and couldn't figure out why. Perhaps this is the reason?

Well, I don't want to get into *why* the xc5000 commands are routed
through the au8522, but I can assure you it's unrelated to the problem
here (well, I *can* tell you if you really care but it's a long
explanation relating to the way the i2c is laid out in the hardware).

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: XC5000 improvements: call for testers!

[Devin Heitmueller]

On Wed, May 13, 2009 at 2:13 AM, kenny wang <smartkenny@gmail.com> wrote:
>
> Hi, Devin
>
> I found another problem for my WinTV-HVR-950Q, but I am not sure if it's
> caused by the device driver: my tvtime sometimes (not often) lost all
> channels and shows a blue window. Switching channel doesn't take the channel
> back. I have to close tvtime and open it again, then it works normally.
> Don't know if it's tvtime's problem. Don't remember if the previous version
> has the same problem (probably does). And I don't know how to debug it or
> where to view any log of it.
>
> Thanks.

Hello Kenny,

Does the blue screen occur when you switch channels?  Or does it occur
when you are currently watching a channel?

It's possible there is a problem where the tuning command gets screwed up.

Can you give me an idea how often it occurs?  One time a minute?  One
time an hour?  One time a day?

And if you could please send me a dump of dmesg the next time it
happens that would help too.

I suspect this is not related to the xc5000 changes.  It's probably a
glitch in the original 950q analog work that just hasn't been noticed
yet.

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: XC5000 improvements: call for testers!

[Britney Fransen]

Devin,

I have an HVR-950q.

Analog support is working much better for me.  I love the faster  
tuning.  Still no luck getting analog to work in MythTV.

I am seeing some major regressions on the the digital side.  mplayer  
can't tune any digital channels and seems to be failing because it  
can't access the tuner.  In MythTV it does tune my QAM64 channel that  
previously would only tune with Frank's QAM64 patch. The other QAM256  
channels either won't lock at all or if they do have bad pixelation  
and audio drops.  In mythtv-setup I can't do a channel scan because it  
says it can't open the card which seems similar to the problem mplayer  
had.  I had previously been using 11658 with the QAM64 patch.

The 950q is definitely cooler to the touch.  Not a big deal but I did  
notice that the tune light that would light orange when tuned to a  
channel no longer lights up.

Let me know if there is anything you would like me to try.

Thanks,
Britney

On May 5, 2009, at 11:14 PM, Devin Heitmueller wrote:

> Hello all,
>
> I'm happy to announce that there have been some considerable
> improvements to the xc5000 driver, and I am looking for people with
> xc5000 based devices to test:
>
> == Noteworthy changes ==
>
> * Power management is now properly supported - no more sucking up your
> laptop battery and burning your fingers on the tuner's f-connector
> when the device is idle (can be disabled with the "no_poweroff"
> modprobe option).
>
> * Faster tuning - average 10x improvement in time to lock.  Average
> lock time now around 350ms, down from 3200ms.  No more multi-second
> delays when trying to channel surf in tvtime.
>
> * Redistributable firmware - Xceive has graciously allowed us to
> redistribute the firmware and bundle it in the distros.  No more need
> for users to manually extract the blob from the Hauppauge Windows
> driver.
>
> * Various fixes to bridges and dvb core found during power  
> management testing.
>
> * Support for DVB-T tuning, thanks to David T.L. Wong <davidtlwong@gmail.com 
> >
>
> To test the code, clone from the following hg repository:
>
> http://linuxtv.org/hg/~dheitmueller/xc5000-improvements-beta/
>
> Unfortunately, current users are going to have to upgrade to the new
> firmware.  However, this is a one time cost and I will work with the
> distros to get it bundled so that users won't have to do this in the
> future:
>
> http://www.devinheitmueller.com/xc5000/dvb-fe-xc5000-1.6.114.fw
> http://www.devinheitmueller.com/xc5000/README.xc5000
>
> Thanks go out to Xceive for providing access to the xc5000
> specification, reference driver code, and firmware under the
> appropriate license.  Thanks also go out to Michael Krufky for his
> considerable effort in helping test/debug different xc5000 hardware.
>
> I look forward to hearing back from testers with any problems they may
> encounter.  Now is the time to bring these up before it gets merged
> into the mainline.
>
> Thanks,
>
> Devin
>
> -- 
> Devin J. Heitmueller
> http://www.devinheitmueller.com
> AIM: devinheitmueller
> --
> To unsubscribe from this list: send the line "unsubscribe linux- 
> media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: XC5000 improvements: call for testers!

[Britney Fransen]

Sorry all about the top posting in the last message.

Re: XC5000 improvements: call for testers!

[Devin Heitmueller]

On Wed, May 6, 2009 at 2:42 PM, Britney Fransen
<britney.fransen@gmail.com> wrote:
> Devin,
>
> I have an HVR-950q.
>
> Analog support is working much better for me.  I love the faster tuning.
>  Still no luck getting analog to work in MythTV.
>
> I am seeing some major regressions on the the digital side.  mplayer can't
> tune any digital channels and seems to be failing because it can't access
> the tuner.  In MythTV it does tune my QAM64 channel that previously would
> only tune with Frank's QAM64 patch. The other QAM256 channels either won't
> lock at all or if they do have bad pixelation and audio drops.  In
> mythtv-setup I can't do a channel scan because it says it can't open the
> card which seems similar to the problem mplayer had.  I had previously been
> using 11658 with the QAM64 patch.
>
> The 950q is definitely cooler to the touch.  Not a big deal but I did notice
> that the tune light that would light orange when tuned to a channel no
> longer lights up.
>
> Let me know if there is anything you would like me to try.
>
> Thanks,
> Britney

Ok, there is alot of information here.  Let me try to break it down.

First off, the QAM64 patches that Frank provided have not been merged
it.  It's on my todo list.

Has the MythTV situation gotten *worse* with this code compared to the
current v4l-dvb tip?  It would not surprise me if there are some
general MythTV issues with the 950q (I am in the process of building a
MythTV box so I can test/debug).  However, I would be surprised if
there were *new* issues.  I do know that mkrufky was mentioning there
was some sort of way to tell MythTV about hybrid devices, so that the
application doesn't try to use both the analog and digital at the same
time - and if you didn't do that then this could explain your issue.

Regarding the mplayer issue, please try this:

<unplug the 950q>
cd v4l-dvb
make unload
modprobe xc5000 no_poweroff=1
<plug in the 950q>

... and then see if mplayer still has issues.  This might be somehow
related to the firmware having to be reloaded taking too long for
mplayer (the firmware has to be reloaded when the chip is woken up
after being powered down).

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: XC5000 improvements: call for testers!

[Britney Fransen]

On May 6, 2009, at 1:50 PM, Devin Heitmueller wrote:

> First off, the QAM64 patches that Frank provided have not been merged
> it.  It's on my todo list.

I see that now.  Weird that MythTV is tuning the QAM64 channel now.   
Could it be related to the DVB-T additions?  Could the DVB-T additions  
cause the QAM256 corruption I am seeing?

> Has the MythTV situation gotten *worse* with this code compared to the
> current v4l-dvb tip?  It would not surprise me if there are some
> general MythTV issues with the 950q (I am in the process of building a
> MythTV box so I can test/debug).  However, I would be surprised if
> there were *new* issues.

Looking at the MythTV logs I would say the situation is better as  
there are fewer errors.  It returns to the menu much quicker so it  
could just be that it is failing before it hits a timeout.

> I do know that mkrufky was mentioning there
> was some sort of way to tell MythTV about hybrid devices, so that the
> application doesn't try to use both the analog and digital at the same
> time - and if you didn't do that then this could explain your issue.

  I believe that mkrufky is referring to input groups.  I do have the  
analog and digital set to the same group.

> Regarding the mplayer issue, please try this:
>
> <unplug the 950q>
> cd v4l-dvb
> make unload
> modprobe xc5000 no_poweroff=1
> <plug in the 950q>
>
> ... and then see if mplayer still has issues.  This might be somehow
> related to the firmware having to be reloaded taking too long for
> mplayer (the firmware has to be reloaded when the chip is woken up
> after being powered down).

Did that and it still failed with the following (same as before):
Playing dvb://2@FOX.
FE_GET_INFO error: 19, FD: 4

DVB CONFIGURATION IS EMPTY, exit
Failed to open dvb://2@FOX.

FOX is the first entry in my .mplayer/channels.conf file.

Thanks,
Britney

Re: XC5000 improvements: call for testers!

[Devin Heitmueller]

Hello Britney,

On Wed, May 6, 2009 at 5:02 PM, Britney Fransen
<britney.fransen@gmail.com> wrote:
> On May 6, 2009, at 1:50 PM, Devin Heitmueller wrote:
>
>> First off, the QAM64 patches that Frank provided have not been merged
>> it.  It's on my todo list.
>
> I see that now.  Weird that MythTV is tuning the QAM64 channel now.  Could
> it be related to the DVB-T additions?  Could the DVB-T additions cause the
> QAM256 corruption I am seeing?

I don't see how that could be the issue.  However, if you want to
confirm, you can just roll back that patch and see if it makes a
difference.

>> Has the MythTV situation gotten *worse* with this code compared to the
>> current v4l-dvb tip?  It would not surprise me if there are some
>> general MythTV issues with the 950q (I am in the process of building a
>> MythTV box so I can test/debug).  However, I would be surprised if
>> there were *new* issues.
>
> Looking at the MythTV logs I would say the situation is better as there are
> fewer errors.  It returns to the menu much quicker so it could just be that
> it is failing before it hits a timeout.

Well, it may return faster if the firmware is already loaded, since
the 3 second tuning request now only takes 300ms.

>> I do know that mkrufky was mentioning there
>> was some sort of way to tell MythTV about hybrid devices, so that the
>> application doesn't try to use both the analog and digital at the same
>> time - and if you didn't do that then this could explain your issue.
>
>  I believe that mkrufky is referring to input groups.  I do have the analog
> and digital set to the same group.

Ok.  Well if you're getting mplayer problems too, then it's probably
not the input groups.

>> Regarding the mplayer issue, please try this:
>>
>> <unplug the 950q>
>> cd v4l-dvb
>> make unload
>> modprobe xc5000 no_poweroff=1
>> <plug in the 950q>
>>
>> ... and then see if mplayer still has issues.  This might be somehow
>> related to the firmware having to be reloaded taking too long for
>> mplayer (the firmware has to be reloaded when the chip is woken up
>> after being powered down).
>
> Did that and it still failed with the following (same as before):
> Playing dvb://2@FOX.
> FE_GET_INFO error: 19, FD: 4
>
> DVB CONFIGURATION IS EMPTY, exit
> Failed to open dvb://2@FOX.
>
> FOX is the first entry in my .mplayer/channels.conf file.

Could you try using azap to tune?

It seems like you have a basic tuning problem, independent of the
application.  So, let's forget about MythTV for now and focus on the
low level tools like mplayer/azap until we are confident that works.

If you want to help debug this, try rolling back the individual
patches until you either get to the starting point of the series or
the code starts working.  Once we know which patch causes it to start
failing, we can go from there.

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: XC5000 improvements: call for testers!

[Britney Fransen]

On May 6, 2009, at 4:10 PM, Devin Heitmueller wrote:
>
> Could you try using azap to tune?
>
> It seems like you have a basic tuning problem, independent of the
> application.  So, let's forget about MythTV for now and focus on the
> low level tools like mplayer/azap until we are confident that works.

Makes sense.  I will try azap next.

> If you want to help debug this, try rolling back the individual
> patches until you either get to the starting point of the series or
> the code starts working.  Once we know which patch causes it to start
> failing, we can go from there.

I will try to help but it will be tomorrow before I can really get  
into it.

> Also, you did stop the mythtv-backend daemon when you ran this test,  
> right?

Yes I did stop myth...frontend and backend.

Britney

Re: XC5000 improvements: call for testers!

[Devin Heitmueller]

On Wed, May 6, 2009 at 5:45 PM, Britney Fransen
<britney.fransen@gmail.com> wrote:
>
> On May 6, 2009, at 4:10 PM, Devin Heitmueller wrote:
>>
>> Could you try using azap to tune?
>>
>> It seems like you have a basic tuning problem, independent of the
>> application.  So, let's forget about MythTV for now and focus on the
>> low level tools like mplayer/azap until we are confident that works.
>
> Makes sense.  I will try azap next.
>
>> If you want to help debug this, try rolling back the individual
>> patches until you either get to the starting point of the series or
>> the code starts working.  Once we know which patch causes it to start
>> failing, we can go from there.
>
> I will try to help but it will be tomorrow before I can really get into it.
>
>> Also, you did stop the mythtv-backend daemon when you ran this test,
>> right?
>
> Yes I did stop myth...frontend and backend.
>
> Britney

Thanks for your help.

I actually setup the tree wrong, so it will be a bit more cumbersome
to step through the patches (there are multiple merges from the
v4l-dvb tip).  I'm going to try to clean it up tonight, which will
make it much more straightforward to step through the series of
patches incrementally to debug issues.

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: XC5000 improvements: call for testers!

[Devin Heitmueller]

On Wed, May 6, 2009 at 5:45 PM, Britney Fransen
<britney.fransen@gmail.com> wrote:
> I will try to help but it will be tomorrow before I can really get into it.
>

Britney,

If you do decide to narrow it down to a particular patch, please
switch over to the following tree first:

http://linuxtv.org/hg/~dheitmueller/xc5000-improvements-beta2

I re-exported the patch series and recreated the tree without all the
intermediate merges from the v4l-dvb tip.  As a result, it will be
much easier to bisect and determine which patch is causing the issue.

Cheers,

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: XC5000 improvements: call for testers!

[Britney Fransen]

On May 6, 2009, at 10:55 PM, Devin Heitmueller wrote:

>
> If you do decide to narrow it down to a particular patch, please
> switch over to the following tree first:
>
> http://linuxtv.org/hg/~dheitmueller/xc5000-improvements-beta2
>
> I re-exported the patch series and recreated the tree without all the
> intermediate merges from the v4l-dvb tip.  As a result, it will be
> much easier to bisect and determine which patch is causing the issue.
>

I finally had some time to do some more testing with the beta2 tree  
and I think most of the issues I had were user error.  Not exactly  
sure what I did wrong before but I am not seeing the reception issues  
or any regressions on the digital side anymore.  I think why I thought  
I was seeing QAM64 was because I was using the wrong tuner.  With the  
beta2 tree my 950q is now adapter1, before it was always adapter2.   
That could be part of what I thought was the reception regression as  
well.

Thanks,
Britney

Re: XC5000 improvements: call for testers!

[Devin Heitmueller]

On Tue, May 12, 2009 at 4:50 PM, Britney Fransen
<britney.fransen@gmail.com> wrote:
> I finally had some time to do some more testing with the beta2 tree and I
> think most of the issues I had were user error.  Not exactly sure what I did
> wrong before but I am not seeing the reception issues or any regressions on
> the digital side anymore.  I think why I thought I was seeing QAM64 was
> because I was using the wrong tuner.  With the beta2 tree my 950q is now
> adapter1, before it was always adapter2.  That could be part of what I
> thought was the reception regression as well.
>
> Thanks,
> Britney

Hello Britney,

Thank you for taking the time to isolate/debug the situation.  The
changes should have no effect on the order of adapter1/adapter2.
Could have just been a coincidence or the order in which you plugged
in the devices compared to what they usually are at boot time.

Glad to see that there are no longer any issues.  Once I get one
outstanding Pinnacle 800i fix in, I will issue a PULL request and this
will go into the mainline.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: XC5000 improvements: call for testers!

[Britney Fransen]

On May 12, 2009, at 3:56 PM, Devin Heitmueller wrote:

>
> Glad to see that there are no longer any issues.  Once I get one
> outstanding Pinnacle 800i fix in, I will issue a PULL request and this
> will go into the mainline.
>

Great!  Any chance the QAM64 patch will make it in too?

Britney

Re: XC5000 improvements: call for testers!

[Devin Heitmueller]

On Tue, May 12, 2009 at 4:59 PM, Britney Fransen
<britney.fransen@gmail.com> wrote:
> Great!  Any chance the QAM64 patch will make it in too?
>
> Britney

The QAM64 support is not related to the xc5000 work, so I won't be
putting it into the same patch series.  However, it is toward the top
of my queue to get that submitted separately once I've had a chance to
review the au8522 registers being programmed.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: XC5000 improvements: call for testers!

[Timothy D. Lenz]

----- Original Message ----- 
From: "Devin Heitmueller" <dheitmueller@kernellabs.com>
To: "Britney Fransen" <britney.fransen@gmail.com>
Cc: "Devin Heitmueller" <devin.heitmueller@gmail.com>; "Linux Media Mailing List" <linux-media@vger.kernel.org>
Sent: Tuesday, May 12, 2009 1:56 PM
Subject: Re: XC5000 improvements: call for testers!


> On Tue, May 12, 2009 at 4:50 PM, Britney Fransen
> <britney.fransen@gmail.com> wrote:
> > I finally had some time to do some more testing with the beta2 tree and I
> > think most of the issues I had were user error. Not exactly sure what I did
> > wrong before but I am not seeing the reception issues or any regressions on
> > the digital side anymore. I think why I thought I was seeing QAM64 was
> > because I was using the wrong tuner. With the beta2 tree my 950q is now
> > adapter1, before it was always adapter2. That could be part of what I
> > thought was the reception regression as well.
> >
> > Thanks,
> > Britney
> 
> Hello Britney,
> 
> Thank you for taking the time to isolate/debug the situation.  The
> changes should have no effect on the order of adapter1/adapter2.
> Could have just been a coincidence or the order in which you plugged
> in the devices compared to what they usually are at boot time.
> 
> Glad to see that there are no longer any issues.  Once I get one
> outstanding Pinnacle 800i fix in, I will issue a PULL request and this
> will go into the mainline.
> 
> Cheers,
> 
> Devin
> 
> -- 
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com


So when this goes main, next time we update from v4l we need the new firmware right?

Re: XC5000 improvements: call for testers!

[Devin Heitmueller]

On Wed, May 13, 2009 at 3:04 PM, Timothy D. Lenz <tlenz@vorgon.com> wrote:
> So when this goes main, next time we update from v4l we need the new firmware right?

Yes.

Now that we have the licensing straightened out, I'll also be working
on getting it bundled into the distros so that users don't have to
download the firmware themselves.  They will get a true "plug and
play" experience.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: XC5000 improvements: call for testers!

[Vanessa Ezekowitz]

On Wed 13 May 2009 2:24:53 pm Devin wrote:
> On Wed, May 13, 2009 at 3:04 PM, Timothy D. Lenz <tlenz@vorgon.com> wrote:
> > So when this goes main, next time we update from v4l we need the new
> > firmware right?
>
> Yes.
>
> Now that we have the licensing straightened out, I'll also be working
> on getting it bundled into the distros so that users don't have to
> download the firmware themselves.  They will get a true "plug and
> play" experience.

Devin, does this license/bundle arrangement also cover the firmware for 
xc3028-based devices?

Re: XC5000 improvements: call for testers!

[Devin Heitmueller]

On Wed, May 13, 2009 at 6:26 PM, Vanessa Ezekowitz
> Devin, does this license/bundle arrangement also cover the firmware for
> xc3028-based devices?

Unfortunately, it does not.  Once I get the xc5000 stuff in though, I
am planning on approaching them about getting firmware licensing under
the same terms for xc3028, xc3028L, and xc4000.

Devin


-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: XC5000 improvements: call for testers!

[Devin Heitmueller]

On Wed, May 6, 2009 at 5:02 PM, Britney Fransen
<britney.fransen@gmail.com> wrote:
> Did that and it still failed with the following (same as before):
> Playing dvb://2@FOX.
> FE_GET_INFO error: 19, FD: 4
>
> DVB CONFIGURATION IS EMPTY, exit
> Failed to open dvb://2@FOX.
>
> FOX is the first entry in my .mplayer/channels.conf file.
>
> Thanks,
> Britney

Also, you did stop the mythtv-backend daemon when you ran this test, right?

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: XC5000 improvements: call for testers!

[John R.]

Devin Heitmueller wrote:

[snip]

> Unfortunately, current users are going to have to upgrade to the new
> firmware.  However, this is a one time cost and I will work with the
> distros to get it bundled so that users won't have to do this in the
> future:
> 
> http://www.devinheitmueller.com/xc5000/dvb-fe-xc5000-1.6.114.fw
> http://www.devinheitmueller.com/xc5000/README.xc5000

I downloaded the tip archive for xc5000-improvements-beta, compiled and 
installed it.  I copied the firmware above into /lib/firmware (where the 
old one was).  However, when the driver loads it still loads the old 
firmware.  If this is a non-linux-media question then feel free to 
direct me where to look.  My searching hasn't yet yielded anything yet.

Thanks,

John

Re: XC5000 improvements: call for testers!

[John R.]

-------- Original Message --------
Subject: Re: XC5000 improvements: call for testers!
Date: Wed, 06 May 2009 19:09:23 -0500
From: John R. <johnr@wowway.com>
To: Linux Media Mailing List <linux-media@vger.kernel.org>
References: <412bdbff0905052114r7f481759r373fd0b814f458e@mail.gmail.com>

John R. wrote:
> Devin Heitmueller wrote:
> 
> [snip]
> 
>> Unfortunately, current users are going to have to upgrade to the new
>> firmware.  However, this is a one time cost and I will work with the
>> distros to get it bundled so that users won't have to do this in the
>> future:
>>
>> http://www.devinheitmueller.com/xc5000/dvb-fe-xc5000-1.6.114.fw
>> http://www.devinheitmueller.com/xc5000/README.xc5000
> 
> I downloaded the tip archive for xc5000-improvements-beta, compiled and 
> installed it.  I copied the firmware above into /lib/firmware (where the 
> old one was).  However, when the driver loads it still loads the old 
> firmware.  If this is a non-linux-media question then feel free to 
> direct me where to look.  My searching hasn't yet yielded anything yet.
> 
> Thanks,
> 
> John

After some off-list pointers by Devin, I tracked this down to user 
error.  I thought I was compiling tip for xc5000-improvements-beta but 
was not.  This is now working and composite input video works well on my 
950Q.  I notice no difference from previous version (wouldn't really 
expect to based on changes).

Thanks,

John

Re: XC5000 improvements: call for testers!

[Devin Heitmueller]

On Thu, May 7, 2009 at 7:21 AM, John R. <johnr@wowway.com> wrote:
> After some off-list pointers by Devin, I tracked this down to user error.  I
> thought I was compiling tip for xc5000-improvements-beta but was not.  This
> is now working and composite input video works well on my 950Q.  I notice no
> difference from previous version (wouldn't really expect to based on
> changes).
>
> Thanks,
>
> John

Glad to hear it's working for you.  If you're using composite, then
you will not see the benefits of the tuning performance, but you
*will* see the power management benefits.  This means the tuner chip
won't be enabled when you're not watching TV, which will result in not
causing as much drain on your battery (if you have a laptop) and the
device will be much cooler.

I am still looking for strategies in the code so that the tuner is not
enabled when capturing on composite or s-video (which will reduce
power consumption further), but the code changes are non-trivial.

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller