Difference between revisions of "DVB-S2 PCIe Cards"

From LinuxTVWiki
Jump to: navigation, search
(Currently Unsupported DVB-S2 PCIe cards:)
(25 intermediate revisions by 11 users not shown)
Line 4: Line 4:
  
 
== Supported DVB-S2 PCIe Cards ==
 
== Supported DVB-S2 PCIe Cards ==
* [[XpressVu PCIe Dual Tuner Card]]
+
* [[DVBWorld DVB-S2 PCIE2006]]  
* [[TBS 6920]]
+
* [[DVBWorld DVB-S2 PCIE2005]]
 +
* [[NetUP Dual DVB S2 CI]] (16/32 APSK support)
 
* [[TeVii S470]]
 
* [[TeVii S470]]
 +
* [[TeVii S471]]
 +
* [[TeVii S480]]
 +
* [[XpressVu PCIe Dual Tuner Card]]
 +
* [[Linux4Media cineS2 DVB-S2 Twin Tuner]]
 +
* [[Mystique SaTiX-S2 Dual]]
  
 
== Currently Unsupported DVB-S2 PCIe cards:==
 
== Currently Unsupported DVB-S2 PCIe cards:==
Line 12: Line 18:
  
 
* Micronas reference design|| STB0899 + STB6100 + Micronas PCIe Bridge (Dual DVB-S2, PCIe, no CI) .... PCIe Bridge driver needs some more work
 
* Micronas reference design|| STB0899 + STB6100 + Micronas PCIe Bridge (Dual DVB-S2, PCIe, no CI) .... PCIe Bridge driver needs some more work
* [[NetUP Dual DVB S2 CI]]
 
 
* [[Prof Revolution DVB-S2 8000 PCI-E]]
 
* [[Prof Revolution DVB-S2 8000 PCI-E]]
  
[[Category:DVB-S2|!DVB-S2 PCIe Cards]]
+
=== Supported by 3rd Party Drivers ===
[[Category:Hardware|DVB-S2 PCIe Cards]]
+
{{3rd_party_drivers}}
 +
* [[DVBSKy]] [[DVBSKY S850]]
 +
* [[DVBSKy]] [[DVBSKY S950]] Advanced [[Montage M88DS3103]] demodulator
 +
* [[DVBSKy]] [[DVBSKY S952]] Advanced Twin [[Montage M88DS3103]] demodulator
 +
* [[TBS6925]] (16/32 APSK support)
 +
* [[TBS 6920]]
 +
* [[TBS 6980/6981 ]]
 +
* [[TBS6984 PCIe DVB S2 Quad Tuner TV Card  ]]  
  
* [DVBWorld DVB-S2 2005 PCI-Express Card]
+
[[Category:DVB-S2| ]]
 +
[[Category:Hardware| ]]

Revision as of 01:46, 24 October 2013

On this page you will find information regarding DVB-S2 PCIe cards.

Please be aware that:
  • The information contained here is likely non-exhaustive and, despite best efforts to do otherwise, may contain errors. (Please help to keep these lists up-to-date so that they are useful for everyone!)
  • If your device is not listed, try:
    • searching the existing mailing list archives:
      • Linux-Media Mailing List (LMML) archives (via vger or .... )
      • or from the older mailing lists (now largely deprecated in favour of the LMML):
        • dvb mailing list archives (via spinics or MARC ... )
        • v4l mailing list archives (via .... )
    • searching for information with Google or other internet search engine
    • by posting a question about the device directly to the LMML (but please do conduct a search first, as it may already have been discussed!)
    • Note: when it comes to support, it is generally a good idea to try the current V4L-DVB sources because some device drivers can be very new and thus may have not made their way into the mainstream kernel.
In any regard, in respect to the above listed suggestions, you may find it to be the case that your device is actually already supported or that experimental support is available.
  • Because the component constitution on many devices are often similar or identical, there may be devices that are unlisted but may actually work with the existing driver framework for previously supported devices. In such a case, your non-listed but working device will likely be reported in your system messages as being one of those previously supported devices. If you encounter such an occurrence, please do report your success on the LMML so that proper detection/identification of your device can be added within the drivers.
  • Lastly, it bears worth repeating the request: Please help to keep these lists up-to-date so that they are useful for everyone!


Supported DVB-S2 PCIe Cards

Currently Unsupported DVB-S2 PCIe cards:

If you own one or more devices from the following list and you want to help with support development, please contact the Linux-Media Mailing List (LMML). Note that if your device is similar to or contains components for which driver development is currently being undertaken, then it is possible that you will pique the(se) developer's interest and can obtain some assistance that, possibly, leads to full support for your device.

However, please note that inquiries to the mailing list:

  • should NOT be treated as an order drop-off line/queue. You're soliciting help from volunteer developers who work on V4L-DVB matters in their spare time, and such work can be non-trivial (i.e. requiring even _thousands_ of hours work). So being demanding is one sure route to being ignored. (Honestly, this point really shouldn't even need to be written, but you'd be surprised at the number of irrational individuals who write into the mailing list demanding this or that).
  • may pass without even garnering a response -- that's a distinct by-product of the fact that there are only a limited number of developers, whom might be able to help, that are associated with the project. Often times, even if they wished to help, their energies are entirely tied up with other projects. In such cases, the best path might be to try to spearhead the driver development for your device yourself, or arrange to hire someone who can.
  • Micronas reference design|| STB0899 + STB6100 + Micronas PCIe Bridge (Dual DVB-S2, PCIe, no CI) .... PCIe Bridge driver needs some more work
  • Prof Revolution DVB-S2 8000 PCI-E

Supported by 3rd Party Drivers

Sometimes a manufacturer forks v4l-dvb all on their own and writes a driver for their device so they can claim Linux support.

In-Kernel Drivers

Advantages:
1. It's possible your device will work.. for the moment.
2. If the manufacturer provides open source drivers with an acceptable license, volunteers could technically implement this code in the Linux kernel for true support. However.. :

Disadvantages:
1. The quality of the code (if open, there are also cases where you just get a binary blob) too often just isn't good enough and there's still too much work to be done to make the device work. There was probably a reason the manufacturer didn't just send their patches to the linux-media mailinglist.
2. Depending on what exactly the manufacturer did, you may have to reinstall the drivers every time your kernel is updated.
3. When the manufacturer stops updating the drivers, the drivers will quickly refuse to install as newer kernels are released.

In case a manufacturer provides open source drivers the patches can be sent to the linux-media mailinglist Linux-Media Mailing List (LMML). Keep in mind however that if the license isn't compatible with the Linux kernel or the quality of the code isn't good enough, these will not become a part of the Linux kernel.

Closed source userspace drivers (mostly Sundtek)

Advantages:
1. Same driver for nearly all Linux versions starting from 2.6.15 on.
2. No need to reinstall drivers when your kernel is updated.
3. Your device could work well.
4. Drivers can be profiled easily and more accurately than in kernelspace.
5. If the driver crashes, it won't crash the kernel. (so the system will stay uneffected).
6. If the manufacturer would stop to support the drivers, the userspace driver will still continue to work with newer Linux systems since the Kernelspace <-> Userspace interfaces are fixed and are not meant to be changed.
7. Application based drivers are modern since they use modern Linux interfaces (eg. stable Userspace USB Interfaces since 2006) which did not exist when legacy Kernel drivers were invented
Disadvantages:
1. You can't look into the sources. For end-users this is generally not a problem, but for programmers and people who like to hack their devices or are trying to fix bugs, it would be a disadvantage. If you just want to watch television, this does not concern you.

Examples: Currently relevant since Linux has an unstable USB 3.0 Kernel stack: Sundtek based tuners are used to debug general USB 3.0 Kernel issues, because the application based drivers themselves cannot crash the system. Such Kernel issues also affect legacy drivers but legacy drivers are able to trigger other problems (follow-up problems) by themselves which could be triggered due the faulty Linux USB 3.0 stack which makes debugging much harder.