In response to ongoing issues with the IR support for dib0700 and firmware 1.20, I spent most of yesterday refactoring the code.
When firmware 1.20 was introduced, the dib0700 switched from a polling model using a USB control message, to the messages being delivered on a USB bulk pipe. The code I originally added would do a blocking read on the pipe with a 50ms timeout. Because the dvb-usb-remote code makes use of the global workqueue, this resulted in the global workqueue being blocked 50% of the time. Also, the synchronous urb_bulk_msg() call would burn excess CPU time (reflected as an abnormal increase in the system’s load average when devices were connected).
These changes convert to using an asynchronous callback, which eliminates the expensive polling.
http://www.kernellabs.com/hg/~dheitmueller/dib0700_ir/
My hope is that as a side-effect, this also plays a little nicer with less-then-perfect USB host controllers, reducing the chance of issues with the Nova-T 500 (which people report as intermittent mt2060 i2c errors after several hours of operation when IR is enabled).
Your work on this is much appreciated.
This will also work for the IR on the 340e DVB-t Stick ?
Thomas,
Yes, this work is targeted at all the products that use the dib0700. In fact, I did the work with the PCTV 801e, which is essentially the US equivalent to the 340e.
Devin
Hello Devin,
I just recently purchased this device (Pinnacle PCTV HD Pro Stick (801e),
and I am still hopeful that analog support is still in the works. I really want to be able to convert my old home videos to digital. I have been following some of your posts in other places, and it seems you have given up on working on this. I hope not. But, either way, thanks for all the work you put into the drivers for this device. The digital driver works great!
Hello Toddr,
This is a pretty common question, and as you can see from other posts, I simply cannot justify the cost of adding analog support to the dvb-usb framework. It’s a huge project, which would cost thousands of dollars in man hours. Without a commercial backer it just isn’t worth it personally to me to spend over a hundred hours developing this functionality when that time could be spent on other projects that I find far more interesting.
In other words, would you want to spend the next two months of nights and weekends working on something you personally find boring, for no compensation?
Cheers,
Devin
OK, thanks anyway. I guess I will have to stick with windows for this functionality. I have a quote you might find interesting “………whose primary goal is to improve the Linux platform for audio / video applications. We’re determined to raise the overall quality bar and improve the GPL drivers for everyone.”
Toddr,
Interesting how a post that started out with me announcing some fixes I was contributing to the community turns into me having to defend whether I am doing something contrary to KernelLab’s stated goal.
One of the advantages of working on this stuff for free is that random people on the Internet don’t get to decide what I work on. And the reality is that I’ve got a dozen projects I’m working on that help out a whole lot more people than the five users who have asked about 801e analog support.
If it really bothers you that much, feel free to learn how to write Linux drivers yourself and add the analog support. In fact, the only reason the 801e has digital support at all under Linux is because I spent 50 or 60 hours implementing it after being annoyed that it didn’t work with that board.
Cheers,
Devin
It doesn’t really bother me. In fact, it doesn’t really bother me to use windows when Linux doesn’t work. That’s what’s great about freedom, I can use whatever I want, just like you have the choice to work on whatever you like. Not a problem. I really appreciate your hard work, as I stated in my initial post. The digital drivers work great!